tusveld@nluug.nl (Fred Tusveld) (05/13/91)
Hello, I have been working on a Esprit project in which we use CLOS. In presenting our project, we are often asked about actual applications delivered in CLOS. Does anyone know of applications written in CLOS that have been delivered? Another interesting question is : are there signs that CLOS is gaining industrial acceptance? Some time ago I heard that an industrial CAD package originally written in C was being ported to CLOS. Fred Tusveld ICT Landdrostlaan 51, 7302 HA Apeldoorn The Netherlands tel. +31 55 498600 hcsrnd!tusveld@hp4nl.nl or hcsrnd!tusveld@relay.EU.net
gillett@AI.MIT.EDU (Walter E. Gillett) (05/19/91)
>Does anyone know of applications written in CLOS that have been delivered? "SitePlanner", a computer-aided engineering (CAE) software package used in cleaning up hazardous waste sites. Developed by ConSolve, Inc., Lexington, MA. >Another interesting question is : are there signs that CLOS is gaining >industrial acceptance? Some time ago I heard that an industrial CAD >package originally written in C was being ported to CLOS. My impression is that industrial use of LISP/CLOS is largely confined to research labs and that its use is, if anything, declining. ConSolve is considering porting SitePlanner to C++ because of problems with LISP. Those problems are (in order of importance to us): 1. Performance. LISP code is always significantly slower than C code, even if one works hard to optimize it. The richness of the language is wonderful for quick development, but makes optimization difficult. One has to be very disciplined (e.g., using destructive rather than copying list operations wherever possible) and the language is sufficiently remote from the machine that it is not always easy to understand the efficiency tradeoffs of using different constructs. Another problem is the amount of run-time overhead resulting from CLOS's flexibility - on-the-fly class and method redefinition, for example. This is great for development, but to achieve reasonable production speed it should be possible to say "OK, I'm finished developing" and compile a fast, inflexible production image. 2. Isolation from mainstream software tools. C programmers can use, for example, the Motif and Open Look GUI toolkits directly. LISP programmers either have to build a foreign function call interface to a C-based application or wait for someone else to provide one. Foreign function calling is not part of the Common LISP standard (therefore the resulting interface is not portable across different LISP implementations), and debugging in a hybrid LISP/C environment is very difficult. 3. Memory hog. The base development image for Sun Common LISP takes 14 MB! While there are tools for reducing delivery image size, the results are still much larger than a comparable C program. 4. Recruiting. It's a lot easier to hire C programmers than LISP programmers. In short, LISP is a wonderful prototyping tool, but is not viable for commercial products (with the exception of specialized niches such as expert systems). C++ may be less powerful, but it is far more practical.
jeff@aiai.edinburgh.ac.uk (Jeff Dalton) (05/23/91)
> My impression is that industrial use of LISP/CLOS is largely confined > to research labs and that its use is, if anything, declining. That is my impression too. However, it seems rather strange that when machines are becomming so much faster and memory so much cheaper we find people thinking it will be a big win to move from, say, KEE to ProKappa. The advanatges of a C-based system are relatively less than they used to be, I would think. > ConSolve is considering porting SitePlanner to C++ because of problems > with LISP. Those problems are (in order of importance to us): > > 1. Performance. LISP code is always significantly slower than C code, > even if one works hard to optimize it. I have encountered a number of cases where Lisp code was faster than C or just as fast, but perhaps they are too exceptional. There are also cases where Lisp is slower for no good reason, so far as I could tell. So I think there is room for Lisp to do better here, at least for some applications, and I'd be interested in knowing what cases Lisp handles poorly. The various Lisp implementors may be interested too. > 2. Isolation from mainstream software tools. C programmers can use, > for example, the Motif and Open Look GUI toolkits directly. LISP > programmers either have to build a foreign function call interface to > a C-based application or wait for someone else to provide one. The interface to such tools is simple in some implementations. However, you are right that the implementors have to prepare the ground for you and that your code will be at least somewhat implementation-dependent. An approach that works well for some applications is have the graphics code written in C but running in a separate process connected to Lisp by a pipe. Windows, menus, etc are represented on the Lisp side by a "handle" such as, perhaps, a string like "window-1". Although there isn't any standard way to make such a pipe connection, it's fairly easy to do it in most Lisps. > 3. Memory hog. The base development image for Sun Common LISP takes > 14 MB! While there are tools for reducing delivery image size, the > results are still much larger than a comparable C program. This is indeed a major pain. -- jd
kanderso@BBN.COM (05/23/91)
Errors-To: commonloops-request@cis.ohio-state.edu
Sender: commonloops-request@cis.ohio-state.edu
Date: Wed, 22 May 91 21:15:01 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: CLOS' popularity
To: "Walter E. Gillett" <gillett@ai.mit.edu>,
tusveld <tusveld@cis.ohio-state.edu>
Cc: commonloops@cis.ohio-state.edu, gillett@ai.mit.edu,
gillett <gillett@cis.ohio-state.edu>
> My impression is that industrial use of LISP/CLOS is largely confined
> to research labs and that its use is, if anything, declining.
There are certainly older Flavor based systems in industrial use. For
example, ALCOA has several Flavor based applications in their plants.
That is my impression too. However, it seems rather strange that
when machines are becomming so much faster and memory so much cheaper
we find people thinking it will be a big win to move from, say, KEE
to ProKappa. The advanatges of a C-based system are relatively less
than they used to be, I would think.
Yes, from what i've read ProKappa sounds like a cleverly disguised LISP in
C clothing. This certainly may have some marketing advantages these days,
but who knows about technical. As time goes on, it may be that C looks at
lot more like LISP. For example, garbage collection is a major issue in
C++ these days.
> ConSolve is considering porting SitePlanner to C++ because of problems
> with LISP. Those problems are (in order of importance to us):
>
> 1. Performance. LISP code is always significantly slower than C code,
> even if one works hard to optimize it.
I have encountered a number of cases where Lisp code was faster than C
or just as fast, but perhaps they are too exceptional.
There are also cases where Lisp is slower for no good reason, so
far as I could tell.
So I think there is room for Lisp to do better here, at least for
some applications, and I'd be interested in knowing what cases Lisp
handles poorly. The various Lisp implementors may be interested too.
I'd be interested too. Certainly vendors have worried a lot about fixnum
arithmetic, etc. Unfortunately, in certain implementation LISP will loose
over C. For example, in some implementations of floating point numbers it
is hard not to cons unnecessary floats. It is also unfortuantely quite
easy to write very slow programs in LISP that you would never think of
writing in C. One example is (reduce #'+ (mapcar ...)).
> 2. Isolation from mainstream software tools. C programmers can use,
> for example, the Motif and Open Look GUI toolkits directly. LISP
> programmers either have to build a foreign function call interface to
> a C-based application or wait for someone else to provide one.
But the foreign function interface is a good way to get to this
"mainstream" software. If you thought about it, you might be able to write
the interface automatically. You could even think of LISP as the glue that
holds your C together. This might give you most of the best of both worlds.
I've only read about programming in C using Motif and Open Look, so correct
me if i'm wrong, but it seems like the first thing they do try to get
around some of the things C is missing - namely lists, keyword arguments,
and closures. This forces one to program in a style that looks akward to
me.
The interface to such tools is simple in some implementations.
However, you are right that the implementors have to prepare the
ground for you and that your code will be at least somewhat
implementation-dependent.
An approach that works well for some applications is have the graphics
code written in C but running in a separate process connected to Lisp
by a pipe. Windows, menus, etc are represented on the Lisp side by a
"handle" such as, perhaps, a string like "window-1". Although there
isn't any standard way to make such a pipe connection, it's fairly
easy to do it in most Lisps.
> 3. Memory hog. The base development image for Sun Common LISP takes
> 14 MB! While there are tools for reducing delivery image size, the
> results are still much larger than a comparable C program.
This is indeed a major pain.
I think LISP can learn a lot from C, but what is a comparable C program to
Sun Common LISP? What are we willing to leave out to make it smaller?
kRick.Busdiecker@cs.cmu.edu (05/23/91)
In article <16144.9105222015@subnode.aiai.ed.ac.uk> jeff@aiai.edinburgh.ac.uk (Jeff Dalton) writes: > ConSolve is considering porting SitePlanner to C++ because of problems > with LISP. Those problems are (in order of importance to us): > > 1. Performance. LISP code is always significantly slower than C code, > even if one works hard to optimize it. I have encountered a number of cases where Lisp code was faster than C or just as fast, but perhaps they are too exceptional. Run-time compilation, in some situations, can be used to great advantage in demonstrating performance quickly and easily in lisp that is very difficult to match with C -- like how many C hackers have really written code that does run-time linking? There are also cases where Lisp is slower for no good reason, so far as I could tell. So I think there is room for Lisp to do better here, at least for some applications, and I'd be interested in knowing what cases Lisp handles poorly. The various Lisp implementors may be interested too. This is a big area of frustration for me. On the one hand, I feel that I am constantly encountering this perceived notion that Lisp Is Slower Than C. On the other hand, I feel that I have a solid technical basis for claiming that this notion of relative speed is based on semi-bogus information. A big problem is that it is much easier, albeit completely unnecessary, to write correct, but *wildly* inefficient lisp code. As a simple case in point, I once knocked more than 50% of the time out of an commercial application with a typical running time in the 6 to 12 hour range, by rewriting about a quarter page of code. The code in question was MAPCARing over the result of a MAPCAR call where the inner call used a :TEST function which was in turning calling MAPCAR on the tail of the original list. None of this consing was at all necessary! All of the partial results were `dropped on the floor', or left for the garbage collector. I rewrote the code such that it produced the same result without consing. I would like to think that this was an extremely uncommon situation, however after having the opportunity to get up close and personal with a handful of other large lisp applications, I now realize that extremely careless memory management is the rule rather than the exception. I would bet that a company that *needed* to get their application faster could achieve similar results at great savings by simply tuning their original application -- even if *only* for memory management -- rather than recoding in C or C++. I'm somewhat skeptical, however, as to whether the typical industrial lisp hacker really understands the issues involved well enough to do the tuning. > 2. Isolation from mainstream software tools. C programmers can use, > for example, the Motif and Open Look GUI toolkits directly. LISP > programmers either have to build a foreign function call interface to > a C-based application or wait for someone else to provide one. The interface to such tools is simple in some implementations. However, you are right that the implementors have to prepare the ground for you and that your code will be at least somewhat implementation-dependent. An approach that works well for some applications is have the graphics code written in C but running in a separate process connected to Lisp by a pipe. Windows, menus, etc are represented on the Lisp side by a "handle" such as, perhaps, a string like "window-1". Although there isn't any standard way to make such a pipe connection, it's fairly easy to do it in most Lisps. Actually, I think that a good argument can be made that there *is* a portable way to do this. Given that having pipes requires having a U*ix operating system, you can write portable C code, using the pipe-fork-n-exec model, which starts up a lisp process with it's standard input and output streams tied to the C program. At the very least, this gives you portability across: - lisp implementations -- the lisp program just starts up normally; it can be prevented from accessing /dev/tty and assumed (yes, *some* lisp implementation, *could* meet spec and fail to deal with this situation -- I don't believe that that implementation exists.) to communicate via its standard input and output streams. The reason that this cannot, strictly speaking, be firmly based within the Common Lisp standard is that start up and shut down are not standardized. This lack is for good reason, given that the concepts don't fit well in, say, a lispm environment. In any case, the assumptions made here about the lisp implementation really are quite reasonable. - C compilers -- In a U*ix they've all got to be able to generate code to make system calls. - U*ix implementations -- the assumptions here are that the OS must provide pipe(2), fork(2) and some form of exec such as execve(2). The other thing that I hope will help to turn this situation around is Python (Rob MacLachlan [CMU Common Lisp group]) and its presumeably forthcoming commercial descendents. Lisp compilers are now truly coming of age, finally providing functionality (like source level debugging support) that C hackers take for granted, and in addition taking advantage of state-of-the-art optimization techniques to crank out some truly tight code. They might not actually eliminate completely bogus consing (?), but they are getting to where they can point you right at the places that are doing it. I really think that moving from Lisp to C is a wrong approach, but I agree that for the most part, industry appears to be moving in that direction. -- Rick.Busdiecker@CS.CMU.EDU ``Now, what I contend is that my body is my own, at least I have always so regarded it. If I do harm through my experimenting with it, it is I who suffer, not the state. - Samuel Langhorne Clemens (a.k.a. Mark Twain)
mthome@BBN.COM (Mike Thome) (05/24/91)
>>> 3. Memory hog. The base development image for Sun Common LISP takes >>> 14 MB! While there are tools for reducing delivery image size, the >>> results are still much larger than a comparable C program. >> This is indeed a major pain. >I think LISP can learn a lot from C, but what is a comparable C program to >Sun Common LISP? What are we willing to leave out to make it smaller? How about Saber's C++ development environment? After all, you get a great deal in that 14 MB: i.e. compiler, interpreter, and debugger as well as the standard lisp "runtime library". So how much different is this from a C++ environment? Well, on my local Sun 4: hello.c compiles to about 24K... But lets be fair and count the shared libc.a (at 500K). Now for the rest of a C++ environment: g++ (160K), cc1plus (2608K), asparc (280K), ld++ (232K), gdb (1120K), make (312K), and libg++.a (> 1024K). Sum 'em up and: 6260K without an interpreter. Now 1/2 the equivalent minimum size isn't bad, and you would still end up with a 24K binary (+ however much of the 500K lib needed to run), but we are most certainly not seeing (the commonly perceived) several orders of magnitude of difference between *truly* comparable C and Lisp programs. cheers, -mik (mthome@bbn.com)
duff@starbase.mitre.org (David A. Duff) (05/24/91)
In <9105231427.AA09586@cheops.cis.ohio-state.edu> kanderso@BBN.COM writes: >Yes, from what i've read ProKappa sounds like a cleverly disguised LISP in >C clothing. This certainly may have some marketing advantages these days, >but who knows about technical. As time goes on, it may be that C looks at >lot more like LISP. For example, garbage collection is a major issue in >C++ these days. have you seen any of the interactive c environments such as sabre c? prokappa is to sabre c roughly as kee was to lucid lisp. saber c gives you a little bit of lispish stuff, such as the ability to redefine functions on the fly, a debugger, the ability to inspect objects, the ability to freely mix compiled and interpretted code. it does this at a price, however - it seems to me to be a much worse memory hog than lisp is. of course, the advantage is that when you're done developing, you can leave the saber environment behind and run in pure c. > > 2. Isolation from mainstream software tools. C programmers can use, > > for example, the Motif and Open Look GUI toolkits directly. LISP > > programmers either have to build a foreign function call interface to > > a C-based application or wait for someone else to provide one. >But the foreign function interface is a good way to get to this >"mainstream" software. If you thought about it, you might be able to write >the interface automatically. You could even think of LISP as the glue that >holds your C together. This might give you most of the best of both worlds. yes, i have done a considerable amount of development with lisp in this mode (lisp as glue). one useful mechanism i have found for doing this is using the RPC protocol. unfortunately, there doesn't seem to be a good publicly available implementation of a lisp/rpc interface. i have hacked together some of the client-side stuff myself in a not-too-portable fashion (i use the foreign-function inteface and load a lot of object code from system libraries rather than writing all the way down to the lowest levels in lisp). ...but it works pretty well for the several systems i've used it on. dave duff mitre corporation 703-883-7731 duff@ai.mitre.org ai technical center mclean, va usa -- dave duff mitre corporation 703-883-7731 duff@ai.mitre.org ai technical center mclean, va usa
larry@tweety.Berkeley.EDU (Larry Rowe) (05/24/91)
I don't like to get into these arguments but sometimes I can't resist... The difference between Saber C++ and Lisp is that it takes me a couple of minutes to recompile the production system and I'm guaranteed that it will be *much* smaller. I agree that more sophisticated performance tuning can often substantially improve the space performance of Lisp, but the problem is it takes a 4-star guru and lots of time, both of which are scarce. Now let's get real. You own a $500K house and you're about to develop a new product for your very own company. Would you bet your house on your ability to produce a *competitive* product using Lisp? I.e., if you have a product that no one buys, you lose your house. That's a big risk and most people making business decisions avoid as many risks as they can. BTW, don't give me the superior productivity argument (i.e., Lisp can produce high function systems rapidly) because I run on an 8 MB Sparcstation and I'm not going to run a >16MB calendar program. Why 8 MB you ask? No good reason. But most commercial companies buy 500 workstations at a time and they can't afford to by an addition 16 MB for every workstation. Larry
tmb@ai.mit.edu (Thomas M. Breuel) (05/25/91)
In article <duff.675023139@starbase> duff@starbase.mitre.org (David A. Duff) writes: >But the foreign function interface is a good way to get to this >"mainstream" software. If you thought about it, you might be able to write >the interface automatically. You could even think of LISP as the glue that >holds your C together. This might give you most of the best of both worlds. yes, i have done a considerable amount of development with lisp in this mode (lisp as glue). Unfortunately, among system programming languages, C is the least suitable for interfacing with other languages. The main reason is C's unfortunate confusion of arrays and pointers. ANSI C has now at least opened the door to letting you view "pointers" as "displaced-to arrays", but it will probably be a long time (if ever) until C vendors catch on to the fact that the information of what range a pointer is valid over should be kept at runtime, both for better error detection, and to allow better interfacing with other languages. Thomas.
davis@barbes.ilog.fr (Harley Davis) (05/27/91)
In article <42236@ucbvax.BERKELEY.EDU> larry@tweety.Berkeley.EDU (Larry Rowe) writes:
Now let's get real. You own a $500K house and you're about
to develop a new product for your very own company. Would you
bet your house on your ability to produce a *competitive* product
using Lisp?
Yes.
I.e., if you have a product that no one buys, you
lose your house. That's a big risk and most people making business
decisions avoid as many risks as they can.
Fortunately, they're buying it.
BTW, don't give me the superior productivity argument (i.e.,
Lisp can produce high function systems rapidly) because I run
on an 8 MB Sparcstation and I'm not going to run a >16MB calendar
program. Why 8 MB you ask? No good reason. But most commercial
companies buy 500 workstations at a time and they can't afford
to by an addition 16 MB for every workstation.
And they shouldn't have to, and they don't.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: davis@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, Franceram+@cs.cmu.edu (Rob MacLachlan) (05/28/91)
I'd like to point out that (at least in the original message) there was more substance to this thread than "C good, Lisp bad". Pretty much everyone who is starting a large new Lisp system is using CLOS, so the real question is "when is programming in Common Lisp appropriate?" >From: gillett@AI.MIT.EDU (Walter E. Gillett) >Subject: CLOS' popularity >Date: 18 May 91 18:33:59 GMT > >"SitePlanner", a computer-aided engineering (CAE) software package used in >cleaning up hazardous waste sites. My impression is that industrial use of >LISP/CLOS is largely confined to research labs [...] ConSolve is considering >porting SitePlanner to C++ because of problems with LISP. [The usual Lisp >problems...] > >In short, LISP is a wonderful prototyping tool, but is not viable for >commercial products (with the exception of specialized niches such as >expert systems). I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has been done by advocating Lisp as being: "The same as FORTRAN/C/Ada, only better". Many of Lisp's efficiency problems can be (and are being) greatly reduced through improved compilers, tuning, delivery and foreign interface tools, but as it stands today, given realistic Lisp and C programs that implement the same algorithm, the C program is guaranteed to be somewhat faster (1.5x to 3x) and much smaller (2x to 5x). C's problems with incremental development, debugging and prototyping can be (and are being) reduced in sophisticated C programming environments such as Saber C, but as it stands today, Lisp prototyping environments have more functionality and are more cost-effective than comparable C prototyping environments. In addition to these contemporary (but subject to change) differences between Lisp and C programming environments, there is also the inherent difference between high-level and low-level programming. In high-level programming, you use (and reuse) powerful operations that are very distant from the hardware implementation. In low-level programming, the hardware implementation is obvious. You can program at different levels in any language, but Lisp encourages high-level programming, and C excels at low-level programming. Many of the advantages (and disadvantages) of Lisp are exactly the advantages (and disadvantages) of high-level programming. High-level programming is easier, but produces a less efficient result. The place where Lisp delivers its benefits is in the pre-production parts of research and development. Lisp is very appropriate in research labs, and is also generally effective for rapid prototyping. Programs that are long-lived (subject to much evolution), but that are sold in small volumes for very high prices may also gain significant benefits during their long maintenance phase. The question key is: "When can a company get away with releasing a product written in Lisp?" I think that the answer is basically "when there is no competition." This is not as restrictive as it might seem; because Lisp excels at rapid development, it is easy for a Lisp program to be the first to market. But in order to hold onto market share after the first couple of years, the company must either: -- Continue to add useful functionality to the Lisp program, maintaining a powerful technological advantage, or -- Reimplement a production version, probably in a lower-level language. The other way in which there may be no competition is under contract. If someone needs a very specialized program, they won't be able to buy it in a competitive market. Instead, they will have to take bids to develop the program. In this situation, the customer is forced to directly pay development costs; if you program using an environment that reduces development costs, you can come in with a lower bid. Robert A. MacLachlan
shebs@Apple.COM (Stan Shebs) (05/30/91)
Kudos to Rob for an incisive description of C vs Lisp issues! In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes: >Lisp and C programming environments, there is also the inherent difference >between high-level and low-level programming. In high-level programming, you >use (and reuse) powerful operations that are very distant from the hardware >implementation. In low-level programming, the hardware implementation is >obvious. You can program at different levels in any language, but Lisp >encourages high-level programming, and C excels at low-level programming. An observation: it's easier to push *up* from a base language than *down*. Experienced C programmers will, over time, develop large libraries of high level functionality for their programs. Extension can be done by using those libraries, optimization by replacing the implementations of those functions with better versions. (Amusingly, the extensions often look like re-implementations of Lisp.) Experienced Lisp programmers, however, start out high-level, and build even higher-level functionality, but have a terrible time trying to optimize the lower-level machinery that limits performance. It's very frustrating to look straight at a piece of list structure and ask "you are a temporary list of known length, why is the system giving you the red carpet treatment in non-ephemeral space?", all the time knowing that if you had done this in C, you could stack-allocate an array and know that nearly every C compiler was going to give you reasonable code. Admittedly, my view of C is somewhat idealized, since bugs do run rampant in those bits of optimized low-level functionality... While we're on the subject, has anybody looked seriously at how well CLOS might compile into C or C++ (for instance, via PCL/KCL)? Stan Shebs Apple ATG System Software shebs@apple.com
tmb@ai.mit.edu (Thomas M. Breuel) (05/30/91)
In article <13715@goofy.Apple.COM> shebs@Apple.COM (Stan Shebs) writes:
An observation: it's easier to push *up* from a base language than *down*.
[...]
Experienced Lisp programmers, however, start out high-level, and build
even higher-level functionality, but have a terrible time trying to
optimize the lower-level machinery that limits performance.
That's not entirely true. Sure, the most commonly used Lisp dialects,
CommonLisp and Scheme, were poorly designed from the point of view of
being able to specify low-level optimizations. However, this is not
an inherent problem with Lisp. Individual implementations of Lisp dialects,
like T and AKCL, let you hand-optimize down to the machine level. The
only problem is that the necessary language constructs are not part
of any standard.
Thomas.jeff@aiai.ed.ac.uk (Jeff Dalton) (05/30/91)
In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes: >I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has >been done by advocating Lisp as being: > "The same as FORTRAN/C/Ada, only better". I agree with much of what you say. It's a mistake to try to compete with FORTRAN/C/Ada on every front. We should emhasise Lisp's strengths rather than its weaknesses. Lisp is higher level, and "many of the advantages (and disadvantages) of Lisp are exactly the advantages (and disadvantages) of high-level programming." However, I think a lot of damage has been done by saying that Lisp shouldn't try to be like C, even though I agree that it shouldn't. It too often functions as a reason for failing to fix problems that should be fixed. For years, I have been hearing that it doesn't matter that Lisp requires vast amounts of memory, because menory is so cheap. For years, I have been hearing that it doesn't matter that Lisp is so poor at delivering applications because it's so great at development. I still don't have a machine that's big enough to run the big Common Lisp implementations together with their programming environments unless I use a machine that I share with many other users and so make it much less useful for them. No matter how good the development environments are, they don't help me unless I can run them. And the C tools I can use aren't as bad as some people seem to think. In a cost benefit analysis, C often comes out ahead even without considering such things as Sabre C. There are a number of other cases where C again comes out ahead. If I want to write a program that uses the X Window System in interesting ways, it's often a choice between writing it in C and being able to run it or writing it in Lisp and watching it page. (A possible compromise is to use C for the graphics part.) I often write little programs, and I'd like to write them in Lisp. Buf if, for example, I want to write a Unix command, I shouldn't write it in Common Lisp, because the runtime overheads are too great. And so on. Quite a bit can be accomplished by picking the right implementation, but it's a pain to end up using several varieties of Scheme and Common Lisp in order to get reasonable results. Too many implementations of Common Lisp seem to have decided that it hardly matters how big they are, thus leaving many users with too little choice. It's convenient to think that Lisp will survive as a development tool while other languages are used for applications. What may happen instead is that (a) development tools for other languages will improve so that Lisp's advanatges are less great, (b) Lisp's reputation as too big and slow will cause many people to think it will be faster to start in C rather than switch to it later on, and (c) as Lisp is used less there will be less incentive to learn it or teach it. A language can be high level without having such problems. Prolog and Scheme are examples. However, in many quarters Lisp is being judged by the performance of commercial Common Lisp systems, not by what can be done with Elk or Scheme-to-C. I will continue ot use Lisp whenever possible. But I want to use Lisp in more cases, more of the time, have greater choice and not pay so big a price. I also want it to work better with C (and other languages) so that I can mix and match. -- jd
gregor@parc.xerox.com (Gregor Kiczales) (05/30/91)
In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:
From: ram+@cs.cmu.edu (Rob MacLachlan)
Newsgroups: comp.lang.clos
Date: 28 May 91 03:35:48 GMT
I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has
been done by advocating Lisp as being:
"The same as FORTRAN/C/Ada, only better".
I agree with much of what has been said in this thread but would like to
add something as well. I believe there is a chance for Lisp to succeed
as a commercial language, and moreover as a commercial language used in
delivered systems. But, before this can happen a number of current
obstacles to using Lisp together with other languages must be resolved.
Here a simple analogy I use when thinking about this. When you build a
car, or an airplane, or a building, you don't build it out of one single
material, nor do you use one single tool. (Ford doesn't build cars out
of steel only with screwdrivers only.) It just wouldn't make sense to
do that. A car is a complex system, its various parts must satisfy a
variety of goals. The simple fact is that different materials and
manufacturing techniques do a better job of meeting those different
goals. While there are a few zealots who argue that everything should
be built out of plastic or ceramics or some other wonder-material, the
common practice is not to do so.
Similarly modern computational systems are large and complex and have
components which must meet a variety of goals. It doesn't make sense to
try and build all of these parts out of the same substrate.
Take for example a modern photocopier. The tasks which much be handled
include: real-time control (for the paper path and imaging system),
window-system like UI functionality (for the control panel), signal
processing (for copy quality adjustments) and data logging (for the
billing and fault-prediction system). There is no reason to believe
that a single programming language, or even a single operating system,
is appropriate for all these tasks.
We need to understand what tasks Lisp is good for and do a better job of
characterizing them. Then, in order to make it possible for Lisp to be
used as part of larger projects, our job, as technicians, is to try and
work out the technical obstacles to writing large systems using a
variety of languages and libraries. The job of our marketing
organizations is to try and work out the financial and legal obstacles
to writing large systems this way.
Only when both of these jobs are done will users be free to write
systems in which each individual part can be done using the best tool
for the job. Until then, users will continue to use a single tool for
the whole job. As long as they are forced into that kind of situation,
I think its fair to say they will choose C more often than Lisp.baechler@disuns2.epfl.ch (Emmanuel Baechler) (05/30/91)
In article <4846@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > > > For years, I have been hearing that it doesn't matter that Lisp > requires vast amounts of memory, because menory is so cheap. For > years, I have been hearing that it doesn't matter that Lisp is > so poor at delivering applications because it's so great at > development. The amount of memory doesn't matter: memory *IS* really cheap today, and SparcStations are cheap CL platforms. In addition, they are really quick at running lisp. They are so quick, that I doubt more and more that there is a provable speed difference with C (for applications of the same style). Their environnment remain primitive, compared with a lisp machine, however they are usable, and much better that the environnments of imperative languages. All the Common Lisp implementations I know are now sold with CLIM, which allow to generate user interfaces in a much more convenient way than directly programming X11. And I do not see any reason why it should be necessary do manipulate directly X11, while much higher level tools are available. Finally, Franz Inc (but I guess Lucid too) has a tool to generate standalone applications, with a minimal lisp kernel, such that the customer do not even see that its application has been built in Lisp. > > Quite a bit can be accomplished by picking the right implementation, > but it's a pain to end up using several varieties of Scheme and Common > Lisp in order to get reasonable results. Too many implementations of > Common Lisp seem to have decided that it hardly matters how big they > are, thus leaving many users with too little choice. > How big is X11, Gnu Emacs, AutoCad, LaTeX? Everybody complain while CL looks big, while none does about all our other favorite tools, which are frequenlty as big, and require quite a lot of memory too. > It's convenient to think that Lisp will survive as a development > tool while other languages are used for applications. What may > happen instead is that (a) development tools for other languages > will improve so that Lisp's advanatges are less great, (b) Lisp's > reputation as too big and slow will cause many people to think > it will be faster to start in C rather than switch to it later > on, and (c) as Lisp is used less there will be less incentive to > learn it or teach it. Lisp will srurvive both as a research and a developpment langugage, because its PRACTICAL power and extensibility make easier to do sophisticated things: they can be programmed at the level required by the problem, instead of "putting down" the problem at the level of the language. The "leading" applications in a few years will be much more sophisticated than the current ones. They will deal with diagnosis, scheduling, financial and economic analysis, ICAD and so on, and these applications are *MUCH* more easily programmed in a high level language like Common Lisp than C, which is just "the power of assembly language with the flexiblity of assembly language" as someone said. Emmanuel Baechler baechler@liasun4.epfl.ch AI Lab. Ecole polytechnique Federale de Lausanne MA - Ecublens 1015 Lausane Switzerland
jeff@aiai.ed.ac.uk (Jeff Dalton) (06/06/91)
In article <1991May30.082921@disuns2.epfl.ch> baechler@disuns2.epfl.ch (Emmanuel Baechler) writes: >In article <4846@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: >> >> For years, I have been hearing that it doesn't matter that Lisp >> requires vast amounts of memory, because menory is so cheap. For >> years, I have been hearing that it doesn't matter that Lisp is >> so poor at delivering applications because it's so great at >> development. > > The amount of memory doesn't matter: memory *IS* really cheap today, >and SparcStations are cheap CL platforms. In addition, they are really >quick at running lisp. In the paragraph following the one you quote above, I wrote I still don't have a machine that's big enough to run the big Common Lisp implementations together with their programming environments ... The machine on my desk is a SPARCstation. The amount of memory does matter. Still. > All the Common Lisp implementations I know are now sold with CLIM Is CLIM available only commercially? Or is there some public domain or nearly public domain version as there was for CLOS, CLX, and CLUE? If the former, it will be much less useful. Theer are many people who can afford KCL + CLX who can't afford one of the commercial Common Lisps. >> Quite a bit can be accomplished by picking the right implementation, >> but it's a pain to end up using several varieties of Scheme and Common >> Lisp in order to get reasonable results. Too many implementations of >> Common Lisp seem to have decided that it hardly matters how big they >> are, thus leaving many users with too little choice. > > How big is X11, Gnu Emacs, AutoCad, LaTeX? Everybody complain while CL >looks big, while none does about all our other favorite tools, which are >frequenlty as big, and require quite a lot of memory too. X11, GNU Emacs, and LaTeX all run reasonably well on the machine on my desk. I don't happen to use AutoCad. -- jd
baechler@disuns2.epfl.ch (Emmanuel Baechler) (06/06/91)
> > In the paragraph following the one you quote above, I wrote > > I still don't have a machine that's big enough to run the big > Common Lisp implementations together with their programming > environments ... > > The machine on my desk is a SPARCstation. > > The amount of memory does matter. Still. In my lab, we have lisp machines (Symbolics) and SparcStations. My desk machine is a Symbolics. However, I use suns from time to time, and I read my mail (and News) on a sun. Their environnment is more primitive than what you can find on a lispm, but they are fast and I never encountered a memory problem, neither did any of my colleages who use them for developpment. All our machines are between 16 and 24 megs, and they work well. > All the Common Lisp implementations I know are now sold with CLIM > > Is CLIM available only commercially? Or is there some public domain > I don't know any public domain version, But I don't believe that this will really harm people: Franz Inc (I guess that it's the same for lucid), has really interesting academic prices, so I doubt that this is a problem, even for people in the universities. Emmanuel Baechler baechler@liasun4.epfl.ch
jeff@aiai.ed.ac.uk (Jeff Dalton) (06/07/91)
In article <1991Jun6.092905@disuns2.epfl.ch> baechler@disuns2.epfl.ch (Emmanuel Baechler) writes: >> In the paragraph following the one you quote above, I wrote >> >> I still don't have a machine that's big enough to run the big >> Common Lisp implementations together with their programming >> environments ... >> >> The machine on my desk is a SPARCstation. > In my lab, we have lisp machines (Symbolics) and SparcStations. My desk >machine is a Symbolics. However, I use suns from time to time, and I read >my mail (and News) on a sun. Their environnment is more primitive than what >you can find on a lispm, but they are fast and I never encountered a >memory problem, neither did any of my colleages who use them for develop- >ment. All our machines are between 16 and 24 megs, and they work well. I don't see why we have to disagree. I am perfectly willing to believe that one of the large commercial Common Lisps will run well on a SPARC that has enough memory. Indeed, that has been my experience too. What you could do in return is recognize that some people don't have enough memory and aren't likely to get enough more in the near future. 16 Meg is ok sometimes, but certainly not always. Using Common Lisp + CLOS + CLX + CLUE, for example, more than 16 meg seemed to be needed; and that was before trying anything like a large application. The plain fact is that a number of people form their opinion of Common Lisp by trying one of the big commercial CLs on machines that aren't up to the job -- even though they are reasonably powerful machines that work fine for a wide range of applications written in C. It would be nice if I could point them to a Common Lisp that would work on their machine. But I can't. And, unlike you, I can't even say "it works for me", because it doesn't. >> All the Common Lisp implementations I know are now sold with CLIM >> >> Is CLIM available only commercially? Or is there some public domain > >I don't know any public domain version, But I don't believe that this will >really harm people: Franz Inc (I guess that it's the same for lucid), has >really interesting academic prices, so I doubt that this is a problem, even >for people in the universities. Well, it won't harm _some_ people. I think it helps a lot that PCL and CLX are free. If to use CLIM one has to buy Franz Inc CL, that will be a problem for some people at least in this University. It also does nothing for those who want to use some other CL such as KCL or CMU CL. -- jd