From ...
From: Erik Naggum <erik@naggum.no>
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" <jonathan@meanwhile.freeserve.co.uk>
| 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