Last Modified: MJS May 9, 1983 1:38 PMFiled on: {Indigo}Loops-AAAI.bravoKnowledge Programming in Loops:Report on an Experimental Courseby Mark Stefik, Daniel G. Bobrow,Sanjay Mittal, and Lynn ConwayKnowledge Systems AreaXerox Palo Alto Research Center3333 Coyote Hill RoadPalo Alto, California 94304Abstract. Early this year fifty people took an experimental course at Xerox PARC on knowledgeprogramming in Loops. During the course, they extended and debugged small knowledge systemsin a simulated economics domain called Truckin. Everyone learned how to use the Loopsenvironment, formulated the knowledge for their own program, and represented it in Loops. At theend of the course a knowledge competition was run so that the strategies used in the differentsystems could be compared. The punchline to this story is that almost everyone learned enoughabout Loops to complete their small knowledge system in only three days. The widespread surpriseat this high level of productivity suggests that the power of integrating multiple programmingparadigms has yet to be widely recognized. 1IntroductionKnowledge programming is concerned with the techniques for representing knowledge incomputer programs. It is important in many applications of AI, where the problems are messy. Asin many situations in life, pat solutions and simple mathematical models just aren't good enough.Things break. Information is missing. Assumptions fail. Situations are complicated. To cope withmessiness, AI researchers have found that large amounts of problem-specific knowledge are usuallyneeded. This places a premium on the use of powerful techniques for representing and testingknowledge in computer programs.Very few people have been trained to build knowledge systems. This is a critical bottleneckthat limits the scope and impact of knowledge engineering. It limits the number of things that canbe tried, the number of good ideas that are propagated, and the number of successful applications,that influence the way that other scientists and the general public perceive the field.A few numbers may serve to put this in perspective. About one computer science researcher inten does some work in AI, and perhaps a fifth of those work in knowledge engineering. In 1980,there were approximately 265 Ph.D. graduates in Computer Science, according to the "SnowbirdReport" (Denning, et al 1981). Fewer than a half dozen doctoral theses appear each year on someaspect of building knowledge systems. An estimate in a brochure by Teknowledge, Inc., indicatesthat there are only about sixty people in the world with high level expertise in the design anddevelopment of knowledge systems. Although precise figures for these populations are difficult toobtain, all the evidence suggests that the community is tiny, indeed. bApF' a)\qiYTrX! zS$,OpF"aNF$L#K> FHsr4" D}G B#tr( @Y ?t r5 =S^ ;-4 90. 7+ 3 u @/rT -&; ,a *Nd ( T &? $@!}\ C +7 W@F W R KN ` -2 U E  >W_2 Our goal is to increase the impact and scale of knowledge engineering bysimplifying the methods of knowledge programming and making them more widelyaccessible. Training in knowledge engineering usually requires several years of study at one of a handful ofuniversities. A group of us in the Knowledge Systems Area at Xerox PARC is trying to shortenthis training time. Our goal is to increase the impact and scale of knowledge engineering bysimplifying the methods of knowledge programming and making them more widely accessible. Indoing this we have developed an experimental knowledge programming system called Loops --(Bobrow & Stefik 1981), (Stefik, et al 1983a). Feedback about the adequacy of Loops is collectedfrom beta-test sites which are using it to build knowledge systems. Feedback about the learnabilityof Loops is collected from the participants in an experimental course (see figure xxx) that we runperiodically. 2Integration and ParadigmsKnowledge programming is concerned with the techniques and paradigms for programmingknowledge in computers. An important principle of knowledge programming is that differentparadigms are appropriate for different purposes. This contrasts with the use of a singleprogramming paradigm for everything, be it logic programming as in Prolog (Clocksin & Mellish1981), lisp programming (Winston & Horn 1978), object-oriented programming as in Smalltalk(Goldberg & Robson 1983), or whatever. An important principle of knowledge programming is that different paradigms areappropriate for different purposes. There are various metrics of cost for applying a programming paradigm across a spectrum ofapplications. Examples of metrics are the cost of learning, the cost of modifying, the cost ofdebugging, and the cost of running. These costs vary across paradigms and applications becausedifferent programming paradigms provide different ways of organizing information in programs.For a given metric and application, some programming paradigms can be more cost-effective thanothers.By allowing for choice and combination of paradigms, a knowledge programming systemenables various costs to be lowered. For example, we attribute much of our success in creating arapid introduction for building knowledge systems to the low costs for learning and applying Loops.For each of the things that the course participants needed to represent in their knowledge systems,there was some paradigm in Loops in which the expression of the knowledge was concise and thelearning cost was low.As indicated in the Loops logo in Figure 1, Loops currently integrates four programmingparadigms:. Nfr b @a2a{a{(a{a{a{a{a{a{" a{$a{'a{){a{+a{.qa{0a{3ga{5a{8]a{:a{=Sa{?a{BIa{Da{G?ab^u@\@ [ Wr @WN2WN{WN{(WN{WN{WN{WN{WN{WN{" WN{$WN{'WN{){WN{+WN{.qWN{0WN{3gWN{5WN{8]WN{:WN{=SWN{?WN{BIWN{DWN{G?WNW@T3U RhK P P N\ MY K>A IsM G+'ur E A uX@=r+) ; N :1) 89<! 6o> 4& 12 @020{0{(0{0{0{0{0{0{" 0{$0{'0{){0{+0{.q0{00{3g0{50{8]0{:0{=S0{?0{BI0{D0{G?012-u7+# (r @(-2(-{(-{((-{(-{(-{(-{(-{(-{" (-{$(-{'(-{){(-{+(-{.q(-{0(-{3g(-{5(-{8](-{:(-{=S(-{?(-{BI(-{D(-{G?(-(@%., #G_ !}M 1, 4* @)* 2/ O KJ  tr1 @ D1& y  N 2>]Q3Procedure-oriented programming: In this paradigm, large procedures are built fromsmall ones by the use of subroutines. Data and programs are kept separate. Mostcomputer languages are like this. The procedure-oriented part of Loops is Interlisp-D(Teitelman 1978), (Xerox 1982). Interlisp-D is shown at the base of the Loops logo tosuggest that it provides the solid foundation, on which the rest of Loops is built.Object-oriented programming: In this paradigm, information is organized in terms ofobjects, which combine both instructions and data. Large objects are built up from smallerobjects. Objects communicate with each other by sending messages. The conventions forcommunicating with an object with messages constitute a message protocol. Standardizedprotocols enable different classes of objects to respond to the same kinds of messages.Inheritance in a class lattice enables the specialization of objects.Access-oriented programming: This paradigm is useful for programs that monitor otherprograms. Its basic mechanism is a structure called an active value, which has proceduresthat are invoked when variables are accessed. A useful way to think of active values is asprobes that can be placed on the object variables of a Loops program. These probes cantrigger additional computations when data are changed or read. For example, they candrive gauges that display the values of variables graphically. Rule-oriented programming: This paradigm is specialized for representing the decision-making knowledge in a program. In Loops, rules are organized into rulesets which specifythe rules, a control structure, and other descriptions of the rules. Two key features of therule language are that it provides techniques for factoring control information from therules, and also dependency-trail facilities, which provide a basis for "explanation" (seefigure xxx) and belief revision. Figure 1. The Loops Logo. This logo illustrates the different paradigms inLoops - procedure-oriented, object-oriented, data-oriented, and rule-oriented.Knowledge bases are used to provide facilities for long term storage anddevelopment of knowledge systems. The ring is intended to suggest that Loopsintegrates the paradigms. They are not just complementary. They are designedto be used together in building knowledge systems. Each paradigm provides a vocabulary and a set of composition methods for organizinginformation in a program. These different organizational methods determine the way thatinformation is factored and shared. Procedure composition: The composition methods of Interlisp-D are forms of familiarcontrol statements for iteration, recursion, and procedure call.Object composition: This paradigm provides several composition methods as shown infigure xxx. The simplest approach is the specialization of methods and variables of asuperclass. In addition, the inheritance lattice (in contrast with an inheritance hierarachy)enables inheritance to be factored. This allows the creation of special classes called Mixins,intended to impart a specific set of behaviors to subclasses. This terminology is borrowedNfr6btr`S%,^D\,*ZS6WtrU MSCR"J PW;NE6KtrIP8t rG;Etr0!C8B%tr256>tr+<3tr ;D9TX7Y5ur 2L @121{1{(1{1{1{1{1{1{" 1{$1{'1{){1{+1{.q1{01{3g1{51{8]1{:1{=S1{?1{BI1{D1{G?12L. ur2-;+E0){+"'t r7 %2 "s @"2"{"{("{"{"{"{"{"{" "{$"{'"{){"{+"{.q"{0"{3g"{5"{8]"{:"{=S"{?"{BI"{D"{G?""s@< 78 l%6tr0 0@6tr 1ur1)*trt r ^Htr !: B L=\g4from Flavors -- (Weinreb & Moon 1981). Another idea is composite objects. This ideaextends the notion of objects to be recursive in structure so that multiple objects can beinstantiated together. Finally, perspectives in Loops are groupings of objects into a higherlevel object, such that each component is a view (or perspective) of the whole. Perspectivesprovide for the forwarding of messages to the appropriate view.Access composition: The main method of composition in this paradigm is the nesting ofactive values. Analogous to the use of multiple probes in measuring a circuit, thiscomposition assumes that the "probes" are for independent instruments and do not interferewith each other.Rule composition: The rule-oriented program provides for the sharing of rules amongrulesets. It makes use of the other paradigms for organizing the interactions between therules. Thus rules can call rulesets directly (using the procedural orientation), or invokerulesets by sending messages (using the object orientation), or invoke rulesets by accessingdata (using the data orientation).Integration has two major themes in Loops: integration to allow the paradigms to be usedtogether in building a knowledge system, integration of a programming environment for creatingand debugging knowledge systems.Some examples illustrate the integration of paradigms in Loops: the "workspace" of a ruleset isan object, rules are objects, and so are rulesets. Methods in classes can be either Lisp functions orrulesets. The procedures in active values can be Lisp functions or rulesets. This style is themeaning of the ring in the Loops logo, that Loops not only contains the different paradigms butintegrates them. The point is that the paradigms are not only designed to complement each other,but also to be used in together in combination. Figure 2. Combining paradigms: The perch approach. Some examples illustrate non-integration of programming paradigms. For example, figure 2shows the connection between Planner and Lisp. Planner was implemented in Lisp, but a programthat used Planner would not call Lisp directly. Figure 3 shows the connection of List operations toProlog. In effect, list operations were added late to Prolog after the initial design, but they have notbeen integrated in a coherent way with the database that underlies Prolog. Figure 3. Combining paradigms: The patch approach. Figure 4 illustrates another approach, illustrated perhaps by the Spice Machine. In thisexample Lisp and Pascal communicate, in a way, over a narrow bridge. Nfrb8tr`SZ^!t r0\]Z?6Wtr&U:SER"6Ntr2LVK[IP'5G"@DI BIU @~@= ? ;AT 9w1/ 7I 5J 4/ 0 @0N20N{0N{(0N{0N{0N{0N{0N{0N{" 0N{$0N{'0N{){0N{+0N{.q0N{00N{3g0N{50N{8]0N{:0N{=S0N{?0N{BI0N{D0N{G?0N0-33 ) @)j2)j{)j{()j{)j{)j{)j{)j{)j{" )j{$)j{')j{){)j{+)j{.q)j{0)j{3g)j{5)j{8])j{:)j{=S)j{?)j{BI)j{D)j{G?)j)@&O7" $U "7- ^ %K  @\2\{\{(\{\{\{\{\{\{" \{$\{'\{){\{+\{.q\{0\{3g\{5\{8]\{:\{=S\{?\{BI\{D\{G?\A3  @x2x{x{(x{x{x{x{x{x{" x{$x{'x{){x{+x{.qx{0x{3gx{5x{8]x{:x{=Sx{?x{BIx{Dx{G?x@]U D @ 2 { {( { { { { { {" {$ {' {){ {+ {.q {0 {3g {5 {8] {: {=S {? {BI {D {G?    =\25Figure 4. Combining paradigms: The bridge approach. The second theme of integration is the integration of the programming environment. Forexample, Loops extends to other paradigms many of the facilities of Interlisp-D, such as the display-oriented break package, editors, and inspectors. In Loops this integration has led to the samesynergy that is exploited in using multiple paradigms for application programs. For example, thenotion of "breaking" on access to a function is extended to breaking on access to a variable byusing active values to invoke the break package; the notion of tracing is extended to the notion ofhaving gauges (see figure xxx) that can monitor the values of variables.3Getting Ready for the First CourseOn January 6, we began to plan the first Loops course that would be offered on January 31 toour beta-test sites. We had a preliminary course outline, but we knew that we needed some way todraw the participants into programming in Loops. The idea of a video game was suggested, sayrocket ships with Loops programs controlling the thrust and phasers. This idea was rejected asbeing both too frivolous, and computationally too expensive. Another suggestion was a game forplacing tiles. We knew from (Malone 1980) that there were principles for making gamesmotivating. Our course participants would be computing professionals drawn from researchorganizations and AI start up companies, who were interested in using Loops for building expertsystems. We needed something that they would find useful and appealing.As brainstorming continued, some pedagogical principles began to emerge. The game shoulddraw on the real world knowledge of our students. Rocket ships and tiles were wrong, becausepeople didn't have experience with such things from their everyday lives. A board game likeMonopoly was considered, and then our first concept of Truckin emerged. It would be a boardgame with road stops. The players would drive trucks around buying and selling commodities.Their job would be to plan a route and make a profit. There would be various hazards along theway, places where goods and profits could be lost. Players would need to buy gas occasionally. The best way to learn about knowledge programming in Loops is by extending asmall knowledge system. By mimicking real life, Truckin would provide the kinds of difficulties that knowledge engineersencounter in building expert systems. We could create a rich and animated simulation environmentfor the "independent truckers". The students would need to add knowledge to make theirautomated players more powerful. The simulation environment should draw on the student's real-world knowledge, and be rich enough to preclude a simple numerical model. Much of the appealof this was that the "common experience" character of Truckin as a domain would enable us toside-step the usual knowledge acquisition bottleneck. The knowledge engineering experience wouldbe accelerated by immediate feedback from the animated simulation. To simplify getting started,we would provide the students with a small expert system. We became convinced that the best wayto learn about knowledge programming in Loops is by extending a small knowledge system. Nfrb4 ^ @^U2^U{^U{(^U{^U{^U{^U{^U{^U{" ^U{$^U{'^U{){^U{+^U{.q^U{0^U{3g^U{5^U{8]^U{:^U{=S^U{?^U{BI^U{D^U{G?^U^@[: M YoC" WH UE T#%tr RE'= Pzur+ KuX"@H6rC FkN DE B,3 A T ?AI =v*/ ;K 9H@6o@ 42+ 2J 17tr /D N -z5* +I (= @'2'{'{('{'{'{'{'{'{" '{$'{''{){'{+'{.q'{0'{3g'{5'{8]'{:'{=S'{?'{BI'{D'{G?'(=$uJ# r @828{8{(8{8{8{8{8{8{" 8{$8{'8{){8{+8{.q8{08{3g8{58{8]8{:8{=S8{?8{BI8{D8{G?8@tr 3 RE 3$ N M (6tr ]5, ` ` ? @\U6 The simulation environment should draw on the student's real-world knowledge,and be rich enough to preclude a simple numerical model. At this point, we had less than a month to create the course materials, lectures, and Truckin.Sleep would become a rare and precious commodity. The Truckin data base began to take shape.The players would start at Union Hall, and would try to be parked at Alice's Restaurant at the endof the game. There would be various kinds of hazards of the road. The player with the most cashat Alice's would win.Wonderfully, Loops was able to accommodate changes as our ideas evolved. Initially, wethought of the hazards as being road stops. This was probably a carry over of our childhoodexperiences with board games. Then we added the idea of "bandits" that could move around justlike the independent truckers. Bandits were represented as an inheritance combination of playersand consumers. We used active values on variables of the road stops to update the display forcommodity prices and inventories. This meant that we did not need to find every place in theprogram where these things could potentially be changed, in order to update the display. Thefeatures of Loops worked for us, providing convenient techniques for factoring the program. Webecame experienced consumers of our own knowledge programming system as we raced to getready for the course. The simulation was designed to cause goal conflicts. A truck going quickly over a rough roadwould probably have its fragile merchandise damaged. A truck going quickly past a weigh stationwould probably get an extra fine, unless he was lucky or the weigh station was busy. On the otherhand, a truck going slowly past a bandit would probably get intercepted. There would be perishablegoods and fragile goods. We considered explosive goods and other such things, but removed themwhen they failed to add anything new to the game. Our pedagogical style was to leave some thingsout in order to keep it simple. A player could take only three kinds of actions: buy, sell, and move. To facilitate the "suspension of disbelief" in watching the animated simulation, artistic attentionhad to be given to the appearances of things. Icons for the various commodities, hazards, andtrucks were created. We experimented with different configurations of the gameboard, movingaway from the outside edge configuration of most gameboards in order to pack enough road stopson the display screen. Highways were drawn next to the road stops, with a gray background andlittle dashed white lines in the center. People looked at intermediate versions of the gameboard andtold us that the abrupt motion of the trucks was startling. We modified the code to simulatebraking so that trucks would slow down as they arrived at their destinations. The visual appearanceof Truckin became seductive. People were drawn into it. The knowledge engineering experience is accelerated by immediate feedback fromthe animated simulation. Prior to the this, we had used a simple gauge in our demo to illustrate the application of activeNfr b @a2a{a{(a{a{a{a{a{a{" a{$a{'a{){a{+a{.qa{0a{3ga{5a{8]a{:a{=Sa{?a{BIa{Da{G?ab^u!,\8 Yor @Y2Y{Y{(Y{Y{Y{Y{Y{Y{" Y{$Y{'Y{){Y{+Y{.qY{0Y{3gY{5Y{8]Y{:Y{=SY{?Y{BIY{DY{G?YYo@UEtr T37tr Rht rtr P5, N@KaI I5' G&8 F># D72, Bl] @K >? = S ;A@7 O 6># 4:M 2p!A 0N .a -"D@) V '.0 & 4( $>S "s3+ G ? H Itr.  @2{{({{{{{{" {${'{){{+{.q{0{3g{5{8]{:{=S{?{BI{D{G?eu6 )r @2{{({{{{{{" {${'{){{+{.q{0{3g{5{8]{:{=S{?{BI{D{G?)@ 4- $ p>\k7values. It was a crude looking gauge and had little generality. We decided to extend the collectionof gauges so that people could use them for debugging and for monitoring their independenttruckers during the simulation. For ideas on style, we collected some professional catalogs ofgauges, and sought advice from Bruce Roberts on the Steamer project. A family of gauges wasdesigned (see figure xxx). Because of the extensive use of multiple inheritance and the interactionson the display between the parts of the hybrid gauges, a number of programming issues surfaced.The gauges went through several design reviews, to make the gauges simpler to use and modify.During these reviews, we created names for certain categories of design errors that we encountered.For example, a grainsize error is a situation where the structural parts of an object (usuallymethods) are factored too coarsely for the fine control needed by its specializations. A replicationerror is a situation where almost the same structure is repeated in parallel classes, instead offactoring it in a way that would allow it to be shared. Such experiences gave us a deeperunderstanding of the programming issues that people would encounter in using the differentparadigms. About two weeks before the course would begin, we sent out notices to our beta-test sitesinviting people to sign up for the course. We expected about a half dozen people to sign up for thecourse. We advertised that our course would provide hands-on experience in extending a "mini-expert system". By word of mouth, the story spread. Over fifty people called us, requesting to geton the list. We split the list in half and scheduled the second course for the end of February. Wedidn't send out any more advertisements. We had gone public and now we had to make it work.Suddenly it was the weekend before the course. We made some guesses about the appropriatedistribution of prices and penalties. We created our first automated player -- the Traveler -- whichwould just travel along the board between Union Hall and Alice's Restaurant. As the Travelercruised tirelessly around the game board, various bugs in the simulation surfaced. Meanwhile, westarted work on a player to specialize in luxury goods called HighRoller. We didn't have time todebug it very well before the course started. We reasoned that the bugs were acceptable, since theywould provide things for the course participants to fix. We were right, but in hindsight, we had alot of gall.4The Courses as ExperimentsSince that weekend we have run two intensive knowledge programming courses, and alsorepeated the second course to a small group using videotape. By the time of publication of thisarticle, the course will have been run for over 100 people. The courses are organized to alternatelectures and hands-on exercises. So far, everyone taking the course has learned enough about theLoops knowledge programming system to do some practice exercises (such as building a new kindof gauge) and extend a knowledge base for a Truckin player.The most important aspect of the courses for our purposes is the opportunity that they provideus for refining both Loops and the course materials. For us, the courses are experiments, fromwhich we are discovering how to make Loops and our teaching methods more effective. The basicstructure of our experimental process is to run a course and to take some measurements. After thecourse, we change some parameters, run the course again and take the measurements again.Afterwards, we examine how the measurements differ and form hypotheses to guide the nextiteration. The measurements are based on the performance of our students in terms of theproblems that they complete and questions that they ask, and also on the results of questionairesthat they return.Nfr bZ `SQ ^4+ \;! Zur B Y)'8 W^M U*9 Str= QZt P4rX Ni7# LL J @GbT Ed C=! BI @7E >mD@:2( 90;tr 7f*t rt r t 5rD 3&t r 2C! 0;<' .q )uX@&,r6 $aL " W ] T 7,tr@(6 4+ 0;# e<& G B 9 ;a p )>\b8 Between the first two courses we changed several parameters of the course, Loops, andTruckin:oWe substantially increased the emphasis on tools and techniques fordebugging, providing heuristics for programming in Loops. Our concept ofdebugging is to provide tools for understanding the behavior of a system.The second course led students to use gauges for monitoring the values ofvariables, explanation facilities (figure xxx) for understanding which rulemade a particular decision, and breaking and tracing facilities for discoveringwhy some rules do not fire.oIn some cases, we introduced intermediate problems in the exercises.We hypothesized that some of the steps between exercises were too difficultto take all at once.oWe fashioned a new starting player for the second course, called thePeddler, which did a better job than HighRoller in factoring the concerns ofan independent trucker. We hypothesized that the issues in restructuringHighRoller were too difficult for the three day course.oWe adjusted the prices and risks in the various commodities toprovide a greater reward and selection pressure for more sophisticated andknowledgeable truckers.oWe improved the browsers, that is, our interactive graphics for"browsing" information in a knowledge base (see figure xxx). We believedthat we could reduce much of the cognitive load for restructuring objects andaccessing information if we provided more effective ways of making the rightinformation visible. oWe fixed troublesome bugs in the rule compiler. During the firstcourse, participants had to struggle with a compiler that did not reliably keepthe generated Lisp code in correspondence with the rules. The weakest player from the second course could easily dominate the best playerfrom the first course. As a result of these changes, the participants in the second course were dramatically moresuccessful than those in the first. In the first course, we had to slip the schedule for the knowledgecompetition by 90 minutes, in order to let people finish preparing their players. In the secondcourse, people had players ready in about half of the allocated time, and spent the remaining timeexploring other aspects of the system and tuning their strategies. Furthermore, the weakest playerof the second course could easily dominate the best player from the first course.People asked far fewer questions in the second course, and were able to complete many moreof the exercises. In addition, the questionaires from the second course came back with radicallyNfr@bR `Str6\vr*[/YL/W ?U*urS>R"tr6Nvr2L.K6Gvr 8Etrt rD; BIt r-6>vr$= 8;A67vr&6ur4:F2p806-3vr9+i$+)9 &, @%2%{%{(%{%{%{%{%{%{" %{$%{'%{){%{+%{.q%{0%{3g%{5%{8]%{:%{=S%{?%{BI%{D%{G?%&,"u/  }r @&2&{&{(&{&{&{&{&{&{" &{$&{'&{){&{+&{.q&{0&{3g&{5&{8]&{:&{=S&{?&{BI&{D&{G?&}@ < A16 v` O c Q@ ., B =\xR9different advice from those from the first course. The general response from the first course was"give us less on rules" and many people indicated substantial concern with many of thefundamental aspects of that paradigm. In the second course, the responses turned completelyaround. They said "give us more on rules and debugging".We hypothesize that in the first course the combination of a faulty rule compiler and lack ofinformation on how to debug programs in this paradigm undermined confidence. During thesecond course, two members of a team were observed staring at a display. One of them said, "whyis it buying tomatoes?", and the other one elbowed him saying "Ask why! Ask why!" -- goadinghim into action at the Loops keyboard. They had learned their lessons well.This process of tuning the course and Loops in response to feedback reflects our interest inmethods for the engineering of knowledge (Conway 1981), (Stefik & Conway 1982). In this case weare engineering languages and techniques for knowledge programming. The courses provide asource of feedback on the effects of changes that we make to the course materials, paradigms andprogramming environments. We expect this evolutionary process to yield further optimizations inLoops --- improving further the ease of learnability and use. In time, we would like to extend ourwork to provide a framework that would simplify the process of creating higher level organizationsin expert systems (Stefik et al 1982).5The Knowledge CompetitionOne of the most rewarding things about the Loops course is the kind of electric excitement thaterupts during a knowledge competition. People seem to project themselves into the players thatthey have created. They have put their player through many simulations and many playingconditions. In a sense, they have taught it everything. But during the competition there is amoment of truth. The rules cannot be changed. Success in the short run is affected by chance, buton average, the most knowledgeable players will win.The randomly generated game board comes up. As the simulation begins, there is a great dealof commentary and jibes as people compare their players. Who's ahead? Who just got robbed? Awonderful thing about Truckin is that the silliness of the ill-fated move is something that all theobservers appreciate almost immediately. For example,oA player may be racing to Alice's Restaurant. One move before thegame ends, and it is unable to resist a business "opportunity" and doesn'tmake it to Alices. oA player may go to the closest place to sell some goods, even if ithappens to be the City Dump, which unfortunately pays a "negative price". oA player may get focused on a tight producer/consumer loop, makingmoney faster than any other player on the board. If it is programmed to buyfuel from stations that it encounters along its route, but there is no gas stationin the tight loop, the team watching the competition will watch dismally asthe fuel gauge drops lower and lower. Eventually the truck runs out of fueland gets towed back to Union Hall where it must start afresh. oA player may try to park next to Alice's Restaurant near the end ofthe game, even if that happens to be the Union Hall, which confiscates allNfr bH `S; ^\ \9@YL O W5# UF S6' R"L@N\ Ltr) K= IP\ GC E8+ CS B%tr =SuX@9r? 8_ 6K'1 4] 2/4 04@-z\ +/0 )tr, (66$vrtr"9! tr6vr; tr.6dvr:4/#H:@ ot r6 vr!tr 3t r =^O10goods and cash. In our experience so far, these oversights happen in the best of players. They provide a source ofmerriment during the competition, and an illustration of just how much knowledge is really neededto be powerful, even in an artificial environment. Success in the short run is affected by chance, but on average, the mostknowledgeable players will win. The knowledge competition also serves as a source of examples and metaphors about the natureof knowledge. One example drawn from the first Loops course illustrates the interplay betweenknowledge and environment. For the first knowledge competition, two teams prepared players bysimply fixing some of the bugs in the HighRoller. They had a private playoff just before thecompetition, and discovered that when both players were in the same game, the inventory of luxurygoods on the game board became exhausted before the end of play. Neither player was able tocope with this situation. One of the heuristics that we now offer to teams preparing for aknowledge competition is to test rules with many copies of the same player competing at once.This interplay between knowledge and environment brings to mind the example of the ant onthe beach (Simon 1981), in which the apparently complex movement of the ant on the beach isattributed to the complexity of the beach environment rather than the complexity of the ant. InTruckin, the "ants" are mechanical and programmable. We have observed that even the complexityof the Truckin environment creates a substantial selection pressure for resourceful andknowledgeable players. To win, the designers of the players must pit knowledge against complexity.Knowledge provides the adaptability needed for mastering the situations in the game.The primary example of metaphors from the knowledge competition inspired the name of theevent. This is the observation that it is truly the knowledge of players that is competing, and themost adaptable player wins. Recently in connection with the interest in fifth generation computers,Feigenbaum and McCorduck (1983) have characterized knowledge as the new "wealth of nations".In the knowledge competition and Truckin, the competitive advantages of knowledge in a player isconcrete and observable in short experiments.The success of the knowledge competition in motivating participation has led us to speculate onways of alleviating the knowledge acquisition bottleneck by triggering participation in a communityof experts. One idea is to create knowledge servers, which accept knowledge over a computernetwork and make themselves available for solving problems. Here again there would be a"competition" between different bodies of knowledge, competing to solve the problems that areposed. 6ImplicationsSometimes the effects of a technological change can be surprising and widespread. We sensethat a technological change is emerging from research on knowledge programming, a change in theinfrastructure for building knowledge systems. This is not to claim that Loops has reached its finalform, or even that Loops will necessarily be the system in which the effects are first widely spread.Nfrb ^4/ \P [3 W @WN2WN{WN{(WN{WN{WN{WN{WN{WN{" WN{$WN{'WN{){WN{+WN{.qWN{0WN{3gWN{5WN{8]WN{:WN{=SWN{?WN{BIWN{DWN{G?WNWT3u6Rh Nr @N2N{N{(N{N{N{N{N{N{" N{$N{'N{){N{+N{.qN{0N{3gN{5N{8]N{:N{=SN{?N{BIN{DN{G?NN@K= IL G^ F$&t r " DZa B/- @5& >E@;R 9C 7<$ 6(tr= 4^LtrEM 2D 0T@-VB +d )Y '< &,tr8 $a-@ C %Y Z#tr N ]  (u @rF Y e Vf Z >]B11The general technological shift is the simplification of techniques for knowledge programming.The shift will have leveraging power in two ways: (1) the freeing of existing knowledge engineersfrom spending a year or two building the bottom of their knowledge representation systems and (2)a measurable acceleration in the progress of the field if the simplified methods trigger an increasein the number or practitioners from 100 to 1000 or more. Knowledge engineering would thenbegin to have a noticeable effect in many areas of our lives. AcknowledgmentsWe extend thanks to x, y, and z for advice and comments on an earlier drafts of this paper.Thanks especially to the participants from Applied Expert Systems, Daisy Systems, ESL, FairchildAI Lab, Lawrence-Livermore Laboratories, Schlumberger-Doll Research Laboratory, SRIInternational, Stanford University, TeKnowledge, and Xerox Corporation for the many helpfulsuggestions during the first two courses, and for the pleasure we had working together andobserving the knowledge competitions.Note: The Loops course is offered periodically by the Knowledge Systems Area at Xerox PARC. Loops is beingmade available to selected Xerox customers that have been designated as beta-test sites. Planning is currently underwayto consider the possibility of developing and supporting Loops as a product, and licensing it to other computer vendors. Need KA Bottleneck reference.Steamer ReferenceBibliography and Further ReadingBobrow, D. G. & Stefik, M. (1981) The Loops Manual. Tech. Rep. KB-VLSI-81-13, KnowledgeSystems Area, Xerox PARC.Clocksin, W. F. & Mellish, C. S. (1981) Programming in Prolog. Berlin: Springer-Verlag.Conway, L. (1981) The MPC adventures: Experiences with the generation of VLSI design andimplementation methodologies. Proceedings of the Second Caltech Conference on Very LargeScale Integration, 5-28.Denning, P. J., Feigenbaum, E., Gilmore, P., Hearn, A., Ritchie, R.W., & Traub, J. (1981) TheSnowbird Report: A discipline in crisis. Communications of the ACM, 24:370-374.Feigenbaum, E., & McCorduck, P. (1983) The fifth generation. Reading, Mass.: Addison-Wesley.Goldberg, A., & Robson, D. (1983) Smalltalk-80: The language and its implementation. Reading,Mass.: Addison-Wesley.Malone, T. W. (1980) What makes things fun to learn? A study of intrinsically motivating computergames. Technical Report CIS-7 (SSL-80-11), Xerox Palo Alto Research Center.Simon, H. A. (1981) The sciences of the artificial, Cambridge, Mass.: The MIT Press.Nfr@b&8 `S5, ^Q \K Z#7 Y)> Tqi@Pr7$ N*6 MO K>J Is5% G%@DZwpH B*wp' A.Zr@:nx@7B 12q .r'tr ), )W(tr %:)$t /)"Pr 7&)*tr tr! 0"t!r)e M))K tr" p@\12Stefik, M., Bobrow, D., & Mittal, S. (1983) Knowledge programming in Loops: Highlights from anexperimental course. Videotaped Report KSA-83-1, Xerox Palo Alto Research Center.Stefik, M., Bell, A. G., & Bobrow, D. G. (1983) Rule-oriented programming in Loops. Tech. Rep.KB-VLSI-82-22, Knowledge Systems Area, Xerox PARC.Stefik, M., & Conway, L. (1982) The principled engineering of knowledge. AI Magazine 3(3):4-16.Stefik, M., Aikins, J., Balzer, R., Benoit, J., Birnbaum, L., Hayes-Roth, F., & Sacerdoti, E. (1982)The organization of expert systems: A tutorial. Artificial Intelligence 18:135-173.Teitelman, W. (1978) Interlisp reference manual. Tech. Report, Xerox Palo Alto Research Center. Weinreb, D., Moon, D. (1981) Lisp Machine Manual. Cambridge, Mass: MIT.Winston, P.H. & Horn, B. K. P. (1981) Lisp. Reading: Addison-Wesley.Xerox Corporation, (1982) Interlisp-D users guide. Pasadena, CA: Xerox Electro-Optical Systems.Nfr b T)`S1! \Zt)[ r% W1t r T3E)Rh0tr N0/ Ktr H&tr Dtr% @>'$f13More Figures to be placed and numbered. Figure x. Loops Course Outline. This three-day course is offered periodically bythe Knowledge Systems Area at Xerox PARC. Figure x. Object Composition in Loops. The inheritance lattice enables manyforms of structural sharing in Loops. The simplest form of specialization (shownat the left), is to create a subclass the overrides and augments variables andmethods inherited from the superclass. Mixins is a term for a special kind ofclass intended to be used as a generic superclass in the system, conferring a set ofcapabilities on subclasses. When multiple superclasses are used, the resultingsubclass is essentially a hybrid. Instances of the subclass mix together theattributes from the superclasses. Perspectives provide a way of grouping objectsto act as views of a higher level object. It provides for the automatic forwardingof messages to the appropriate perspective. Figure x. The Loops Gameboard -- played by small knowledge systems calledindependent truckers. The little squares on the board are road stops, connectedby the highway drawn above. They are producers, consumers, rough roads,weigh stations. Roadstops with icons are producers, where players can buy.Those with words (e.g., Clothing) are consumers, where players can sell. Thetrucks for the players are shown parked or moving along the highway (e.g.,Sanjay). To the right, a panoply of gauges is being used to monitor the status ofvarious players. In the upper left corner, a rule for one of the players is beingtraced. Figure x. Seeing the Knowledge behind a decision. In this figure the game isinterrupted, causing the Rule Exec window to pop up. The user has asked thesystem why his truck picked a particular stopping place, and Loops has displayedthe rule that made the decision. Figure x. Class Browser on Commodities. Browsers are interactive programsused to browse through a knowledge base. The lines in a class browser indicateNfr bp' ^r @^U2^U{^U{(^U{^U{^U{^U{^U{^U{" ^U{$^U{'^U{){^U{+^U{.q^U{0^U{3g^U{5^U{8]^U{:^U{=S^U{?^U{BI^U{D^U{G?^U^[: ur#Yo) U @U2U{U{(U{U{U{U{U{U{" U{$U{'U{){U{+U{.qU{0U{3gU{5U{8]U{:U{=SU{?U{BIU{DU{G?UU R @R42R4{R4{(R4{R4{R4{R4{R4{R4{" R4{$R4{'R4{){R4{+R4{.qR4{0R4{3gR4{5R4{8]R4{:R4{=SR4{?R4{BIR4{DR4{G?R4RO urMO;KJI(trGKF$*%DZtr(Bt r"@!2>+ ; @;12;1{;1{(;1{;1{;1{;1{;1{;1{" ;1{$;1{';1{){;1{+;1{.q;1{0;1{3g;1{5;1{8];1{:;1{=S;1{?;1{BI;1{D;1{G?;1; 8 @727{7{(7{7{7{7{7{7{" 7{$7{'7{){7{+7{.q7{07{3g7{57{8]7{:7{=S7{?7{BI7{D7{G?784 u?2sr$1H/DF-ztr+*)+'(-%&O " @"2"{"{("{"{"{"{"{"{" "{$"{'"{){"{+"{.q"{0"{3g"{5"{8]"{:"{=S"{?"{BI"{D"{G?"" k @2{{({{{{{{" {${'{){{+{.q{0{3g{5{8]{:{=S{?{BI{D{G?k u&r/)#d1 ( @2{{({{{{{{" {${'{){{+{.q{0{3g{5{8]{:{=S{?{BI{D{G?(  @_2_{_{(_{_{_{_{_{_{" _{$_{'_{){_{+_{.q_{0_{3g_{5_{8]_{:_{=S_{?_{BI_{D_{G?_ Dur$ ytrA 2<~] 14superclass relationships. For example, in this figure, a StereoSystem is aLuxuryGood, an Appliance, and a FragileCommodity. Browsers can be created toshow other relationships too. By selecting nodes in a browser with a mouse, auser can access further information. Figure x. Loops Gauges. Gauges are debugging tools used to monitor the valuesof variables. They can be thought of as probes, that can be inserted onto thevariables of an arbitrary Loops program. Gauges are defined in Loops as classes,and driven by active values -- the mechanism behind data-oriented programmingin Loops. A browser at the bottom of the figure illustrates the relationshipsbetween the classes of gauges. From this figure, we can see that the DigiMeter isa combination of a Meter and an LCD. Nfrb/ t r`St rtrtr^E\$ YL @X2X{X{(X{X{X{X{X{X{" X{$X{'X{){X{+X{.qX{0X{3gX{5X{8]X{:X{=SX{?X{BIX{DX{G?XYL U @U2U{U{(U{U{U{U{U{U{" U{$U{'U{){U{+U{.qU{0U{3gU{5U{8]U{:U{=SU{?U{BIU{DU{G?UURhu r8P9N)(MA K> DIs4trGtrtr D7 @C2C{C{(C{C{C{C{C{C{" C{$C{'C{){C{+C{.qC{0C{3gC{5C{8]C{:C{=SC{?C{BIC{DC{G?CD7 @~<~'$ TIMESROMAN TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN MATH  TIMESROMAN TIMESROMAN   9& 0 ; EM V `gj uzj/}{loops-aaai.bravoStefikMay 9, 1983 5:42 PM