From ... From: Erik Naggum Subject: Re: Can I use Lisp? Date: 2000/10/24 Message-ID: <3181391107929417@naggum.net>#1/1 X-Deja-AN: 685281054 References: <16savskpras2on0vjcfmq2km962sbtcian@4ax.com> <8t44r6$3pc$1@nnrp1.deja.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 972403059 4981 195.0.192.66 (24 Oct 2000 15:57:39 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 24 Oct 2000 15:57:39 GMT Newsgroups: comp.lang.lisp * glauber | In my (limited) experience, CLISP is often fast enough. In the PC, well | optimized code often runs as fast compiled in CLISP as it does in Corman Lisp | (a machine-language compiler). Corman beats CLISP easily on sloppy code, | though... CLISP is often good enough as long as you do not write any functions of your own that implement any abstractions that require multiple calls to user-land functions. CLISP's performance dichotomy between its C-implemented compiled runtime functions and your byte-compiled Lisp functions leads programmers to optimize at a low abstraction level because they are penalized for their abstractions. This is not a good thing for a Lisp environment, where we want to encourage function calls and make abstractions as inexpensive as possible. We don't want people _not_ to use Common Lisp because of performance issues or to think that only built-ins are fast because they are written in C. Approach CLISP as a good toy implementation of Common Lisp, and move on to a real compiler if you ever plan to investigate performance issues. #:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard