Large-Scale System Development in Several Lisp Environments

1. INTRODUCTION

Over the past six months we have been engaged in implementin~ ROSS {an object-oriented, knowledge-based simulation language [7j) and SWIRL (an air battle simulation [5, 6!) in five different Lisp environments. We discovered that the environments varied consid­ erably in how well they supported system development. We report upon our experience by comparing the various environments in terms of cpu usage, real-time usage, and user aids (e.g., editors and file packages). Our aim is to critically examine several Lisps avail­ able today, in order to help those who are building large systems to make an informed choice about which dialect may be most appropriate for their application.

2. FIVE IMPLEMENTATIONS OF ROSS AND SWIRL

2.1. Macllsp on a DEC-20

Maclisp, running under TOPS-20, was the original language in which ROSS was implemented. Approximately one man-year was required to make ROSS a reasonably mature object-oriented pro­ gramming environment. Two factors greatly contributed to the speed of ROSS development. First, Maclisp has a very efficient implementation on the DEC-20 that made it possible to quickly experiment with additions and changes to the ROSS design. (Of course, the speed of Maclisp also contributed to the efficiency of the SWIRL simulation written in ROSS. As may be seen in Table 1, the implementation in the Maclisp-ROSS version is, overall, the fastest of all implementations of SWIRL.) Second, within Maclisp, we could make use of Emacs, a powerful screen-oriented editor, that runs locally within Maclisp through the use of the LEDIT package. Emacs had two features that were crucial to efficient program development . First, Emacs understands Lisp structures (e.g., it does automatic s-expression indentation , pretty-printing and parentheses balancing). Second, when using Emacs to edit a function definition, one directly edits the file containing the function. The user is in full control over not only the format of function definitions, but also exactly how the functions are arranged in files, and therefore in hardcopy when printed .

What hindered the development of ROSS in Maclisp was the poor documentation of many essential language features. Orten novice Maclisp users regard Maclisp as primitive, especially compared to lnterlisp, which advertises such user packages as the Clisp iterative facility , the record package, the filepackage, and the PRINTOUT printing facility . In fact all these features exist in Maclisp, but until recently , unless you had a Mac lisp wizard around, the only way to find out about them was by browsing through the files your machine's Maclisp directory. This kind of search cost us at least a month in development time.

t The view~ expre:t!ed in tbi!l paper a.re the a.uthor:t' own a.nd do not repre:~ent those of Ra.nd or a.ny of ih rese&rch sponso~ .

tions with Emacs in Maclisp, one changes both the definition and appearance, since one is editing a file and a function simultaneously.

The Dolphin operating system does not provide a tree structured directory system, so that files cannot be stored as lo~ically as one would like them to be. The high bandwidth (3 Mbitsfsec) ethernet communication network connecting the Dolphins and the VA...X11/780 allows one to quickly transfer large files between different stations.

2.4. Inter lisp on a V AX-11/780 [1[

Bringing the ROSS/SWIRL system up in VAX-Interlisp did not turn out to be as straightforward as we had expected even though we had already developed ROSS/SWIRL in lnterlisp-D. Though lnterlisp-D source code was almost completely transportable, certain subtle incompatibilities were fairly time consuming to discover. It took about one and a half man-months to bring the ROSS/SWIRL system up.

As with Jnterlisp-D, speed was the main factor slowing both pro­ gram development and hindering subsequent effective use of the SWIRL simulation . This slowness is partly due to working in a time-sharing environment and partly due to the sheer size of Inter­ lisp and the overhead involved in evaluating an expression (e.g .. DWIM, CLISP). We regard the lnterlisp-V AX version of ROSS as marginal for serious simulation applications.

One inconvenience of Jnterlisp-VAX, not shared by the other Inter­ lisp implementations, is that UNIX file names are restricted to at most 14 characters and do not have version numbers. Although Jnterlisp does attempt to simulate version numbers, it does so at the UNLX level. These files all look alike and what results can be seri­ ously confusing at times. Also, considerable caution must be exer­ cised while manipulating files in UNIX since it is very easy to delete or overwrite them.

Since the conversion task involved a non-trivial amount of file mani­ pulations (editing, copying, deleting) the process was helped immensely by the availability .,: excellent file editors (Emacs and the local Rand editor E) , ar,.sl by the UNIX software support. We rarely had occasion to use thr Inter lisp structure editor .

2.5. lnterllsp on a DEC-20 [10]

ROSS/SWIRL has been most recently developed for lnterlisp on the DEC-20. It took about one man-week to bring up this version. Yet, several factors made this a surprisingly painful process. Among other things, the backquote facility (for defining macros) had to be redefined. We also found that files had to be massaged in format considerably so that lnterlisp-10 would accept them. However, because of the extremely efficient disk operations on the DEC-20, the powerful Emacs editor, the friendly TOPS-20 operating system (which has among other features, excellent backup support, tree structured file directories, altmode completion), and useful TOPS-20 resident software, it was possible to go through several iterations of the system fairly rapidly. Even so, SWIRL ran substantially slower than the corresponding implementation in Maclisp on a DEC-20.

3. DISCUSSION

Through several years of experience in developing large Lisp-based systems we have formed certain opinions about features in various Lisp environments, and their effect upon programmer productivity. We summarize these below.

First, as perhaps with any software development effort, the total turnaround time between writing a piece of code and testing it out should be minimal. This implies that the cycle of obtaining fresh Lisp sessions, loading files, executing code, modifying code, and stor­ ing changes should be as rapid as possible. We found that Maclisp, Franzlisp and Jnterlisp-10 satisfied this requirement, but lnterlisp-D and Interlisp-VAX did not . A major bottleneck in Interlisp-D pro­ gram development concerned file operations. Not only did they take a long time to complete, but there was also a lack of a good file editor. We had to use the file editors on the VAX, particularly when converting some of SWIRL files from Maclisp into lnterlisp, and suffered a substantial increase in the number of time-consuming steps needed to make a change on disk . Also, Jnterlisp is much bigger than Maclisp or Franzlisp, and its large size causes frequent swapping at run time leading to considerable deterioration in execu­ tion speed. The presence of user aids (e.g. DWIM, Masterscope, ProRrammers Assistant) if not deactivated , further adds to the time needed to produce a response. Even whiie programming in Inter­ lisp, we found we had rare occasion to use many of these features . In the case of lnterlisp-D, for example, DWIM operated so slowly that it was quicker for the user to detect and correct his own spel­ ling error~ .

Secondly, we found it more desirable to create our code by directly writing into files, instead of defining functions within Lisp, and using MAKEFILE to write them out to disk, as is done in lnterlisp. In our opinion, good programming style refers not only to the struc­ ture of functi ons, but also to the organization of functions into larger, logically connected units of code. If it is difficult for the pro­ grammer to maintain full control over the appearance of large hunks of code or files , it eventually becomes very hard for him to keep a good cognitive map of his programs. Without such a map, the programmer 's understanding of his program, and the rate at which he can modify it, diminishes as the system grows larger. Maclisp and Franzlisp give the programmer complete control over the organization of code. Obtaining such control in lnterlisp is pos­ sible, but indirect, awkward, and time consuming.

Finally . we have come to increasingly believe that speed is as impor­ tant a tool for software development as any sophisticated user inter­ face . AI has been notorious for ignoring efficiency issues. Many research applications run in interpreted Lisp. Often there is no decent Lisp compiler, and where there is, even good Lisp hackers do not know the special compiler declarations needed to make good use of compilation. As AI moves from developing theoretically interest­ ing but computationally light sy~tems into a market place that demands computationally-intensive, scaled-up systems that must run in real time, there will be an increasing need for "industrial­ strength Lisps". These would include, for example, comp;lers that are well documented, heavily optimized, that run in the same environment as the interpreter, and that are guaranteed t<, produce code that runs the same as interpreted code. Presently no compiler meets all these requirements, although Common Lisp [9] hopes to meet these goals.

4. REFERENCES

1. Bates, R. L., Dyer , D. , and Koomen, J . Implementation of Inter lisp on the VAX. Pro c. 1 U82 A CM Symposium on Lisp and Fun ctional Programming, Pittsburgh, Hl82.
2. Foderaro, J.K. , and Sklower, K.L. The Franz Lisp Manual. University of California, Berkeley, April 1982.
3. Gabriel , R.P ., and Masintcr , L.M. Performance of Lisp Systems. Proc. JU82 ACM Symposium 011 Lisp and Functional Program­ ming, Pittsburgh , 1982.
4. Klahr , P ., and Faught, W. S. Knowledge-Based Simulation. Proc. AAA/·80, Stanford, 1980.
5. Klahr, P., McArthur, D., and Narain, S. SWIRL: An Object­ Oriented Air Battle Simulator. Proc. AAA/-82, Pittsburgh, 1982.
6. Klahr, P., McArthur, D. , and Narain, S. SWIRL: Simulating Warfare in the ROSS Language. N-1885-AF, The Rand Cor­ poration, Santa Monica, September 1982.
7. 17] McArthur , D. , and Klahr, P. The ROSS Language Manual. N1854-AF, The Rand Corporation, Santa Monica, September 1982.
8. Sandewall, E. Programming in the Interactive Environment: The Lisp Experience. ACM Computing Sun·eys 10(1), March 1978.
9. Steele, G. An Overview of Common Lisp. Proc. JU82 ACM Symposium on Lisp and Functional Programming, Pittsburgh, 1982.
10. Teitelman , W. lnterlisp Reference Manual. Xerox Palo Alto Research Center , October 1978.
11. Teitelman, W., and Masinter, L. The Interlisp Programming Environment. IEEE Computer 14(4), April 1981.
12. 112] Xerox PARC, Interlisp-D User's Guide. Xerox Palo Alto Research Center, February 1982.

Notes for Table 1.

• (llMaclisp times are averages over three runs on a DEC-20 (approxi­ mate load averages of 1.5) with 1.25 megabytes of physical memory.
• ( 3 ltnterlisp-D is Chorus release of February , 1983. Timings are averages over three runs on a Xerox 1100 Dolphin with 1 mega.­ byte of physical memory. (Timings on a Dolphin with 1.5 mega­ bytes memory averaged between 6% and 19% faster .)
• ( 2 lFranzlisp version is Opus 38 (Apri~ 1982). Timings are averages over three runs on a VAX 11/780 1Ioad averages of less than 1.5) with 4 megabytes of physical memory.
• (i)Jnterlisp-VAX is April, 1982 release. Timings are averages over three runs on a VAX 11/780 (approximate load averages of 1.1) with 4 megabytes of phys1cal memory.
• (s)lnterlisp-10 timings are averages over three runs on a DEC-20 (approximate load averages of 1.5).
• ! 7 lFirst value is for first time EMACS is invoked; second is for sub­ sequent invocations. No cpu time is given because editing is done outside of Lisp.
• ( 6 )f'irst value is for first time LEDif is invoked; second is for subse­ quent invocations. First value is higher because the LEDIT sub­ fork must be created. No cpu time is given because editing is done outside of Lisp.
• lHJTime to invoke the DEDIT local editor (first/second times).
• (o)First value is for first edit , second is for subsequent edits. First value includes time to fetch interpreted function from a file into ~n otherwise compiled environment.
• 11 Time taken to save a file in EMACS editor .
• l 10 )Time to invoke EDITF (first/second times).
• ( 12 lTime required to execute MAKEFILE on a file of 33,550 bytes after one function definition had been changed. RC option was y,ot used.
• ( 13 Time required to execute MAKEFILE on a file of 35,177 bytes after one function definition had been changed. RC option was pot used .
• (liJTime required to execute MAKEFILE on a file of 35,177 bytes after one function definition had been changed. RC option was pot used .
• ( 16 JA pre-release Interlisp-V AX version of April, 1983 is smaller (3,214,304 bytes) and seems about 40% faster .
• ( 15 JOpus 38.50 (February, 1983) is larger (938,614 bytes for SWIRL sysout, 605,302 bytes for Franzlisp) with about the same perfor­ fllance.
• < 17 1Even though SWIRL code could be compiled and run inside of lnterlisp-10, the loader generated an error when loading compiled SWIRL files. We have not been able to fix this error.