From ... From: Erik Naggum Subject: Re: New to Lisp question: advantages of Lisp syntax? Date: 1999/06/03 Message-ID: <3137374233008473@naggum.no>#1/1 X-Deja-AN: 485141327 References: <7j1lm3$bph$1@news8.svr.pol.co.uk> <3137271818084864@naggum.no> <7j375m$90q$1@news8.svr.pol.co.uk> <3137329919324438@naggum.no> <7j4dge$467$1@news6.svr.pol.co.uk> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * "Jonathan" | Actually I found out by accident. that's good, because almost everything good in life happens by accident. | I was hunting down scripting language resources, someone suggested I | checkout Kawa or Lava (JVM Schemes) and that lead to a very interesting | set of decision tree algorithms that told me that CL's old slow execution | speed problems have been solved. (Excution speed is critical for my | work. Lisp is going to have to work with C and assembly on projects I | might use it for.) earlier you said they said "Lisp is slow", now you're modifying it to "Common Lisp is slow". the latter has _never_ been true. the former is true of interpreted Scheme environments and other toy stuff that wants to enjoy the "Lisp" label. of course, older Lisp environments were serious enough, but predate several important advances in Lisp technology. one such example is Emacs Lisp, which is based on an old Lisp in use at MIT, which was for all practical purposes superseded by Common Lisp. so saying that Common Lisp is slow is like saying that C++ doesn't have classes, because Lisp is slow and C doesn't have classes. one of the more important things you'll observe from the Lisp community is that it is a _union_ of communities, with all that that implies, such as not having all that much in common. Common Lisp is a _particular_ Lisp, which means it shares a host of qualities with other Lisps, most of them being quite abstract. however, it also means there are differences from the other Lisps, and one of them is that it is not a toy Lisp best suited for students to make implementations of in a one-semester class. if you object to your peers thinking that Common Lisp is slow, I would agree that they deserve to be corrected. we can live with the history of Lisp: yes, it once was slow and resource-intensive, and misconceptions from that history are legitimate. it is not, however, legitimate to believe that changes important enough to change the name of the language were unimportant. now, the reason I'm being quite heavy on this is that execution speed is not critical for more than 0.01% of the work people do with computers, despite beliefs to the contrary. there are several ways to know whether speed is _really_ critical to your work: (1) you upgrade to the top of the line processor the day it is announced, (2) you port your application to new environments when it can save you 5% execution time, (3) you spend 99% of the time on developing the application in the time profiler, (4) you do custom compilation, and (5) you have enough memory that you will never hit the disk in paging and all your file systems are in memory. if even one of these isn't true for you, execution speed is not critical, but some other choice is. if all you're really after is "fast enough", which is what most people are, the important word is "enough" not "fast", strange as that may seem to someone from the C++ world. if you want immediate response at the front-end of your application, but back-end stuff can be scheduled for less-critical execution time, you will win big by putting requests on the "dregs queue". it's hard to do this in languages other than Common Lisp, so most people don't consider that possibility, but operating system designers have thought in just these terms for decades. using Allegro Common Lisp (www.franz.com) and its very strong multiprocessing support, I have managed to layer my code such that response times are extremely low, but the system keeps working for up to 5 seconds after servicing a request, without hurting the response time for the next request at all. of course, we pay for this in terms of total CPU time spent and the internal scheduling is far from cheap, but the end result is actually _far_ better response times than I could imagine myself getting from a C-based application, and let's heed the old adage: if you don't use the CPU power now, it's gone forever, so whether the CPU is idle or performs low-priority tasks when not servicing high-priority tasks is quite literally irrelevant. you can and should use such unlikely relations to your advantage if you want high performance, as distinctly opposed to high speed. #:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century