Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!pacbell.com!pacbell!att!cbnewsc!lgm From: lgm@cbnewsc.att.com (lawrence.g.mayka) Newsgroups: comp.lang.misc Subject: Re: More LISP stuff Message-ID: <1990Jun28.235822.20608@cbnewsc.att.com> Date: 28 Jun 90 23:58:22 GMT References: <10431@chaph.usc.edu> Organization: AT&T Bell Laboratories Lines: 54 A few clarifications and elaborations: In article vyq@mentor.cc.purdue.edu (William Burdick) writes: >The advantage of having a large body of general data types and >operations is well established in the software engineering community >and it is perhaps the main reason that object-oriented languages are >becoming more and more popular. Common LISP is not object oriented >(CLOS, the Common LISP Object System is object-oriented, though), but >it shares some of the advantages with object-oriented languages that C >does not. Before CLOS, industrial Common Lisp applications often used either Flavors or Loops, CLOS' predecessors. Genera, Symbolics' workstation operating system and development environment, is written using Flavors. Even without CLOS or Flavors or Loops, Common Lisp has garbage collection, run-time behavior selection (to a fair extent), and an extensible hierarchy of datatypes - the three distinguishing marks of OOP, according to "Smalltalk-80: Bits of History, Words of Advice" (page 10). >Of course you will want to compile functions after testing them. But >as W seems to miss, while you are testing them, it is much easier to >test with an interpreter, where you can reload your functions while >the program is running. That is, of course, why C interpreters are >starting to become popular (Objectworks by ParcPlace, for C++, is one >example). Actually, we should distinguish between incremental loading and actual interpretation. Common Lisp can incrementally load either compiled or interpreted functions into either a compiled or interpreted environment, with transparent cross-calling. ObjectWorks for C++ does not include a C++ interpreter at all, as far as I know, but it is admired for its incremental loading capability (a rarity in the C/C++ world). >in C, you are not programming in C. The point here is that in order >to use functional operators (and we used them a lot in our MUD) when >you are writing in C, you have to build them from scratch; a waste of >time you could otherwise be spending on writing your MUD. As for >looping operators (I'm assuming W means functions which loop over a >collection of data), those are just more of the functions you have to >write to support your data types which you had to define, when you >could have used the ones already provided in LISP. Much of the convenience of functional and iterative operators is lost, however, if one doesn't have lexical closures. (C/C++ does not, Common Lisp does.) Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.