diff options
author | Ian Darwin <ian@cvs.openbsd.org> | 1998-09-20 22:21:52 +0000 |
---|---|---|
committer | Ian Darwin <ian@cvs.openbsd.org> | 1998-09-20 22:21:52 +0000 |
commit | 6546b5961d52840b5a9d454ddb5170b111d2afdc (patch) | |
tree | fd0295e4db6f4c4dae193f1fa7beb5bebcbfa960 /share | |
parent | 272c238b9194d34cac9c383517eebd94f9236b96 (diff) |
import of learn-doc
Diffstat (limited to 'share')
-rw-r--r-- | share/doc/02.learn/COPYRIGHT | 23 | ||||
-rw-r--r-- | share/doc/02.learn/Makefile | 11 | ||||
-rw-r--r-- | share/doc/02.learn/learn.ms | 1375 |
3 files changed, 1409 insertions, 0 deletions
diff --git a/share/doc/02.learn/COPYRIGHT b/share/doc/02.learn/COPYRIGHT new file mode 100644 index 00000000000..6c8831163ad --- /dev/null +++ b/share/doc/02.learn/COPYRIGHT @@ -0,0 +1,23 @@ +.\" /**************************************************************** +.\" Copyright (C) AT&T 1995 +.\" All Rights Reserved +.\" +.\" Permission to use, copy, modify, and distribute this software and +.\" its documentation for any purpose and without fee is hereby +.\" granted, provided that the above copyright notice appear in all +.\" copies and that both that the copyright notice and this +.\" permission notice and warranty disclaimer appear in supporting +.\" documentation, and that the name of AT&T or any of its entities +.\" not be used in advertising or publicity pertaining to +.\" distribution of the software without specific, written prior +.\" permission. +.\" +.\" AT&T DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, +.\" INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. +.\" IN NO EVENT SHALL AT&T OR ANY OF ITS ENTITIES BE LIABLE FOR ANY +.\" SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER +.\" IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +.\" ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF +.\" THIS SOFTWARE. +.\" ****************************************************************/ diff --git a/share/doc/02.learn/Makefile b/share/doc/02.learn/Makefile new file mode 100644 index 00000000000..c3f1c0f54c3 --- /dev/null +++ b/share/doc/02.learn/Makefile @@ -0,0 +1,11 @@ +# $OpenBSD: Makefile,v 1.1 1998/09/20 22:21:50 ian Exp $ +# @(#) This version did not come via Berkeley, but direct from Bell Labs. + +DIR= usd/02.learn +SRCS= COPYRIGHT learn.ms +MACROS= -ms + +paper.ps: ${SRCS} + ${TBL} ${SRCS} | ${ROFF} > ${.TARGET} + +.include <bsd.doc.mk> diff --git a/share/doc/02.learn/learn.ms b/share/doc/02.learn/learn.ms new file mode 100644 index 00000000000..15b17d0245b --- /dev/null +++ b/share/doc/02.learn/learn.ms @@ -0,0 +1,1375 @@ +.RP +.\" .TM "79-1274-xx 79-1273-yy" 39199 39199-11 +.ND January 30, 1979 +.\" .TM "76-1274-6 76-1273-5" 39199 39199-11 +.TL +LEARN \(em Computer-Aided Instruction on UNIX +.br +(Second Edition) +.AU "MH 2C-518" 6021 +Brian W. Kernighan +.AU "MH 2C-569" 6377 +Michael E. Lesk +.AI +.\" .MH +.\" .OK +.\" CAI +.AB +.PP +This paper describes the +second version of the +.I +learn +.R +program for interpreting CAI +scripts on +the +.UX +operating system, +and a set of scripts that provide a computerized introduction +to the system. +.PP +Six current scripts cover basic commands and file +handling, the editor, additional file handling commands, the +.I +eqn +.R +program for mathematical +typing, +the ``\-ms'' package of formatting macros, +and an introduction to the C programming language. +These scripts now include a total of +about 530 lessons. +.PP +Many users from a wide variety of backgrounds have used +.I learn +to acquire basic UNIX skills. +Most usage involves the first two scripts, +an introduction to +.UX +files and commands, and +the +.UX +editor. +.PP +The second version of +.I learn +is about four times faster than the previous one +in CPU utilization, +and much faster in perceived time +because of better overlap of computing and printing. +It also requires less file space than the first version. +Many of the lessons have been revised; +new material has been added to reflect changes +and enhancements in +.UX +itself. +Script-writing is also easier +because of revisions to the script language. +.AE +.\" .CS 11 2 13 4 0 0 +.NH +Educational Assumptions and Design. +.PP +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. +.PP +Most lessons fall into one of three types. +The simplest presents a lesson 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. +.PP +The second type asks for a word or number as an answer. +For example a lesson on files might say +.IP +.I +How many files are there in the current directory? +Type ``answer N'', where N is the number of files. +.R +.LP +The student is expected to respond (perhaps after experimenting) with +.LP +.I + answer 17 +.R +.LP +or whatever. +Surprisingly often, however, the idea of a substitutable argument +(i.e., replacing +.I +N +.R +by +17) +is difficult for non-programmer students, +so the first few such lessons need real care. +.PP +The third type of lesson is open-ended \(em +a task is set for the student, +appropriate parts of the input or output are monitored, +and the student types +.ul +ready +when the task is done. +Figure 1 shows a sample dialog that illustrates the last of these, using two +lessons about the +.I cat +(concatenate, i.e., print) command taken +from early in the script that teaches +file handling. +Most +.I learn +lessons are of this form. +.KF +.TS +box, center; +c. +T{ +Figure 1: Sample dialog from basic files script +.sp +(Student responses +in italics; `$' is the prompt) +.nf +.sp +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". +$ \fIcat food\fR + this is the file + named food. +$ \fIready\fR + +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". +$ \fIcat President\fR +cat: can't open President +$ \fIready\fR + +Sorry, that's not right. Do you want to try again? \fIyes\fR +Try the problem again. +$ \fIls\fR +\&.ocopy +X1 +roosevelt +$ \fIcat roosevelt\fR + this file is named roosevelt + and contains three lines of + text. +$ \fIready\fR + +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".... +.fi +T} +.TE +.sp +.KE +.PP +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. +.br +.PP +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 +.I +learn +.R +scripts +only measure performance, not comprehension. +If the student can perform a given task, that is deemed to be ``learning.'' +.[ +%A B. F. Skinner +%T Why We Need Teaching Machines +%J Harvard Educational Review +%V 31 +%P 377-398 +%D 1961 +.] +.PP +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. +.PP +Along with this goes the assumption that +anything can be taught to anybody if it can +be broken into sufficiently small pieces. Anything +not absorbed in a single chunk is just subdivided. +.PP +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. +.PP +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. +.PP +The main reason for using the +.I +learn +.R +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. +.PP +.I Learn +also provides a mechanical check on performance. +The first version in fact would not let +the student proceed unless it +received correct answers to the questions +it set and it would not tell a student the right answer. +This somewhat Draconian approach has been moderated +in version 2. +Lessons are sometimes badly worded or even just plain wrong; +in such cases, +the student has no recourse. +But if a student is simply unable to complete one lesson, +that should not prevent access to the rest. +Accordingly, the current version of +.I 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. +It is still true that +.I learn +will not tell the student the right answer. +.PP +Of course, there are valid objections to the +assumptions above. +In particular, 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. +.NH +Scripts. +.PP +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 construction 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. +.PP +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 understands 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. +.PP +There are some preliminary items which the student must +know before any scripts can be tried. In particular, +the student must know how to connect to +a +.UX +system, +set the terminal properly, +log in, +and execute simple commands (e.g., +.ul +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. +A brief description on paper is provided (see Appendix A), although +assistance will be needed for the first few +minutes. This assistance, however, need not be highly skilled. +.PP +The first script in the current set deals with files. It assumes +the basic knowledge above and teaches the student about +the +.I ls , +.I cat , +.I mv , +.I rm , +.I cp +and +.I diff +commands. +.tr ~ +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 +.ul +ls +command. +.PP +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. +.PP +The second script trains students in the use +of the +.UX +context editor +.I ed , +a sophisticated editor +using regular expressions for searching. +(See section \f2ed\f1 (I). +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. +.PP +A comparison of sizes may be of interest. The +.ul +ed +description +in the reference manual is 2,572 words long. The +.ul +ed +tutorial +.[ +%A B. W. Kernighan +%T A Tutorial Introduction to the Unix Editor ed +%D 1974 +.] +is 6,138 words long. +The fast track through +the +.ul +ed +script is 7,407 words of explanatory messages, and the +total +.ul +ed +script, 242 lessons, +has 15,615 words. +The average +.ul +ed +lesson is thus also about 60 words; the largest +is 171 words and the smallest 10. +The +original +.ul +ed +script represents about three man-weeks of effort. +.PP +The advanced file handling script deals with +.ul +ls +options, +I/O diversion, pipes, and supporting programs like +.I pr , +.I wc , +.I tail , +.I spell +and +.I 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. +.PP +A fourth script covers the +.ul +eqn +language for typing mathematics. +This script must be run on a terminal capable of printing +mathematics, for instance the DASI 300 and similar Diablo-based +terminals, or the nearly extinct Model 37 teletype. +Again, this script is relatively short of tracks: +of 76 lessons, only 17 are in the second track and 2 +in the third track. +Most of these provide additional practice for students +who are having trouble in the first track. +.PP +The +.I \-ms +script for formatting macros +is a short one-track only script. +The macro package it describes is no longer the standard, +so this script will undoubtedly be superseded +in the future. +Furthermore, the linear style of a single learn script is somewhat +inappropriate for the macros, since the macro package is composed of many +independent features, and few users need all of them. +It would be better to have a selection of short lesson +sequences dealing with the features independently. +.PP +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 +.ul +The C Programming Language, +.[ +%A B. W. Kernighan +%A D. M. Ritchie +%T The C Programming Language +%I Prentice Hall +%D 1978 +.] +but this job is not complete. +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. +.PP +This combination of scripts covers much of the material which any +.UX +user +will need to know +to make effective use of the system. +With enlargement of the advanced files +course to include more on the command interpreter, there +will be a relatively complete introduction to +.UX +available via +.ul +learn. +Although we make no pretense that +.ul +learn +will replace other instructional materials, +it should provide a useful supplement to existing tutorials and reference manuals. +.NH +Experience with Students. +.PP +.I +Learn +.R +has been installed on +many different +.UX +systems. +Most of the usage is on the first two scripts, so these +are more thoroughly debugged and polished. +As a (random) sample of user experience, +the +.I 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 passing 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. +On our system 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. +.PP +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 +.I 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; +a +.UX +expert can do the scripts at approximately 30 seconds +per lesson, most of which is the system printing. +.PP +At present working through a section of the middle of the files +script took about 1.4 seconds of processor time per lesson, +and a system expert typing quickly took 15 seconds of real time per lesson. +A novice would probably take at least a minute. +Thus a UNIX system could support ten students working simultaneously +with some spare capacity. +.NH +The Script Interpreter. +.PP +The +.I +learn +.R +program itself merely interprets scripts. It provides +facilities for the script writer to capture student +responses and their effects, and simplifies the job +of passing control to and recovering control 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. +.PP +The file structure used by +.I learn +is shown in Figure 2. +There is one parent directory (named \f2lib\f1\^) containing the script data. +Within this directory are subdirectories, one for each +subject in which a course is available, +one for logging (named +.I log ), +and one in which user sub-directories +are created (named +.I play ). +The subject directory contains master copies of all lessons, +plus any supporting material for that subject. +In a given subdirectory, +each lesson is a single text file. +Lessons are usually named systematically; +the file that contains lesson +.I n +is called +.I Ln . +.br +.KF +.sp +.TS +center, box; +c s s s +l l l l. +Figure 2: Directory structure for \fIlearn\fR +.sp +.nf +lib +.if t .sp .5 + play + student1 + files for student1... + student2 + files for student2... +.if t .sp .5 + files + L0.1a lessons for files course + L0.1b + ... +.if t .sp .5 + editor + ... +.if t .sp .5 + (other courses) +.if t .sp .5 + log +.TE +.sp +.KE +.PP +When +.I +learn +.R +is executed, it makes a private directory +for the user to work in, +within the +.I +learn +.R +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. +.PP +The script writer must provide certain basic items +in each +lesson: +.IP (1) +the text of the lesson; +.IP (2) +the set-up commands to be executed before the user gets control; +.IP (3) +the data, if any, which the user is supposed to edit, transform, or otherwise +process; +.IP (4) +the evaluating commands to be executed after the user +has finished the lesson, to decide whether the answer is right; +and +.IP (5) +a list of possible successor lessons. +.LP +.I +Learn +.R +tries to minimize the work +of bookkeeping and installation, so +that most of the effort involved in +script production is in planning lessons, +writing tutorial paragraphs, +and coding tests of student performance. +.PP +The basic sequence of events is +as follows. +First, +.I learn +creates the working directory. +Then, for each lesson, +.I 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 +.UX +commands. +The user mode terminates when the user +types +.I yes , +.I no , +.I ready , +or +.I 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. +.PP +Let us illustrate this with the script +for the second lesson of Figure 1; +this is shown in Figure 3. +.KF +.sp +.TS +center, box; +c. +T{ +Figure 3: Sample Lesson +.sp +.nf +#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 +.fi +T} +.TE +.sp +.KE +.LP +Lines which begin with +# are commands to the +.I learn +script interpreter. +For example, +.LP +.ul + #print +.LP +causes printing of any text that follows, +up to the next line that begins with a sharp. +.LP +.ul + #print file +.LP +prints the contents of +.I file ; +it +is the same as +.ul +cat file +but has +less overhead. +Both forms of +.I #print +have the added property that if a lesson is failed, +the +.ul +#print +will not be executed the second time through; +this avoids annoying the student by repeating the preamble +to a lesson. +.LP +.ul + #create filename +.LP +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. +.LP +.ul + #user +.LP +gives control to the student; +each line he or she types is passed to the shell +for execution. +The +.I #user +mode +is terminated when the student types one of +.I yes , +.I no , +.I ready +or +.I answer . +At that time, the driver +resumes interpretation of the script. +.LP +.ul + #copyin +.br +.ul + #uncopyin +.LP +Anything the student types between these +commands is copied onto a file +called +.ul +\&.copy. +This lets the script writer interrogate the student's +responses upon regaining control. +.LP +.ul + #copyout +.br +.ul + #uncopyout +.LP +Between these commands, any material typed at the student +by any program +is copied to the file +.ul +\&.ocopy. +This lets the script writer interrogate the +effect of what the student typed, +which true believers in the performance theory of learning +usually +prefer to the student's actual input. +.LP +.ul + #pipe +.br +.ul + #unpipe +.LP +Normally the student input and the script commands +are fed to the +.UX +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. +Accordingly, the material between +.ul +#pipe +and +.ul +#unpipe +commands +is fed +continuously through a pipe so that such sequences +work. +If +.ul +copyout +is also desired +the +.ul +copyout +brackets must include +the +.ul +pipe +brackets. +.PP +There are several commands for setting status +after the student has attempted the lesson. +.LP +.ul + #cmp file1 file2 +.LP +is an in-line implementation of +.I cmp , +which compares two files for identity. +.LP +.ul + #match stuff +.LP +The last line of the student's input +is compared to +.I stuff , +and the success or fail status is set +according to it. +Extraneous things like the word +.I answer +are stripped before the comparison is made. +There may be several +.I #match +lines; +this provides a convenient mechanism for handling multiple +``right'' answers. +Any text up to a +# on subsequent lines after a successful +.I #match +is printed; +this is illustrated in Figure 4, another sample lesson. +.br +.KF +.sp +.TS +center, box; +c. +T{ +Figure 4: Another Sample Lesson +.sp +.nf +#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 +T} +.TE +.sp +.KE +.LP +.ul + #bad stuff +.LP +This is similar to +.I #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. +.LP +.ul + #succeed +.br +.ul + #fail +.LP +print a message +upon success or failure +(as determined by some previous mechanism). +.PP +When the student types +one of the ``commands'' +.I yes , +.I no , +.I ready , +or +.I answer , +the driver terminates the +.I #user +command, +and evaluation of the student's work can begin. +This can be done either by +the built-in commands above, such as +.I #match +and +.I #cmp , +or by status returned by normal +.UX +commands, typically +.I grep +and +.I 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 successfully passed the lesson. +.PP +Performance can be logged: +.LP +.ul + #log file +.LP +writes the date, lesson, user name and speed rating, and +a success/failure indication on +.ul +file. +The command +.LP +.ul + #log +.LP +by itself writes the logging information +in the logging directory +within the +.I learn +hierarchy, +and is the normal form. +.LP +.ul + #next +.LP +is followed by a few lines, each with a successor +lesson name and an optional speed rating on it. +A typical set might read +.LP +.nf + 25.1a 10 + 25.2a 5 + 25.3a 2 +.fi +.LP +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 tiee +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 devel such +that the users get 80% right answers. +The maximum rating is limited to 10 afd the minimum to 0. +The initial rating is zero unless the studeft +specifies a differeft rating when starting +a session. +.PP +If the student passes a lesson, +a new lesson is sedected 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. +.I bye , +bye, +which causes a graceful exit +from the +.ul +learn +system. Hanging up is the usual novice's way out. +.PP +The lessons may form an arbitrary directed graph, +although the present program imposes a limitation on cycles in that +it will not present a lesson 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 +.I #next +line). +From the previous lesson with alternatives one route was taken +earlier; the program simply tries a different one. +.PP +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. +.PP +The driver program depends heavily on features +of +.UX +that are not available on many other operating systems. +These include +the ease of manipulating 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 interrupts, +and of course +the pipeline mechanism itself. +Although some parts of +.ul +learn +might be transferable to other systems, +some generality will probably be lost. +.PP +A bit of history: +The first version of +.I learn +had fewer built-in words +in the driver program, +and made more use of the +facilities of +.UX . +For example, +file comparison was done by creating a +.I cmp +process, +rather than comparing the two files within +.I learn . +Lessons were not stored as text files, +but as archives. +There was no concept of the in-line document; +even +.I #print +had to be followed by a file name. +Thus the initialization for each lesson +was to extract the archive into the working directory +(typically 4-8 files), +then +.I #print +the lesson text. +.PP +The combination of such things made +.I learn +slower. +The new version is about 4 or 5 times faster. +Furthermore, it appears even faster to the user +because in a typical lesson, +the printing of the message comes first, +and file setup with +.I #create +can be overlapped with the printng, +so that when the program +finishes printing, +it is really ready for the user +to type at it. +.PP +It is also a great advantage to the script maintainer +that lessons are now just ordinary text files. +They can be edited without any difficulty, +and +.UX +text manipulation tools can be applied +to them. +The result has been that +there is much less resistance +to going in and fixing substandard lessons. +.NH +Conclusions +.PP +The following observations can be made about +secretaries, typists, and +other non-programmers who have used +.I learn : +.IP (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. +.IP (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 +.UX +to supplement the existing +programmer oriented bulky manual and bulky reference card. +.IP (c) +The concept of ``substitutable argument'' is hard +to grasp, and requires help. +.IP (d) +They enjoy the system for the most part. +Motivation matters a great deal, however. +.LP +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. +.PP +The normal way of proceeding has been to have students in the same +room with someone who knows +.UX +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. +Also, both training and initial work should take place on days +when the +.UX +hardware and software +are working reliably. +Rarely is all of this possible, but the closer one comes the better +the result. +For example, if it is known that the hardware is shaky one day, it is better +to attempt to reschedule training for another one. Students are very +frustrated by machine downtime; when nothing is happening, it takes +some sophistication and experience to distinguish +an infinite loop, a slow but functioning program, +a program waiting for the user, and a broken machine.* +.FS +* We have even known an expert programmer to decide the computer +was broken when he had simply left his terminal in local mode. +Novices have great difficulties with such problems. +.FE +.PP +One disadvantage +of training with +.I +learn +.R +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 +.UX +system. +New users should have manuals (appropriate for their level) and +read them; the scripts ought to be altered +to recommend suitable documents and urge +students to read them. +.PP +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 +\(em 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 facilities make it easy +to watch for lessons that no one +can pass, +but it is still a problem. +.PP +The biggest problem with the previous +.I learn +was speed (or lack thereof) \(em +it was often excruciatingly slow +and made a significant drain on the system. +The current version so far does not seem +to have that difficulty, +although some scripts, +notably +.I eqn , +are intrinsically slow. +.I eqn , +for example, +must do a lot of work even to print its introductions, +let alone check the student responses, +but delay is perceptible in all scripts +from time to time. +.PP +Another potential problem is that it is possible +to break +.ul +learn +inadvertently, by pushing interrupt at the wrong time, +or by removing critical files, +or any number of similar slips. +The defenses against such problems +have steadily been improved, to the point +where most students should not notice difficulties. +Of course, it will always be possible to break +.I +learn +.R +maliciously, but this is not likely to be a problem. +.PP +One area is more fundamental \(em +some +.UX +commands are sufficiently global in their effect +that +.ul +learn +currently +does not allow them to be executed at all. +The most obvious is +.I 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 +.I cd , +but ultimately lessons on such topics probably should be added. +.NH +Acknowledgments +.PP +We are grateful to all those who have tried +.ul +learn, +for we have benefited greatly from their +suggestions and criticisms. +In particular, +M. E. Bittrich, +J. L. Blue, +S. I. Feldman, +P. A. Fox, +and +M. J. McAlpin +have provided substantial feedback. +Conversations with E. Z. Rothkopf also provided 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. +.\" .SG \s-2MH\s0-1273/4-\s-2MEL/BWK\s0-unix +.[ +$LIST$ +.] |