Subject: Re: garnet performance issues
From: Erik Naggum <>
Date: 1999/02/12
Newsgroups: comp.lang.lisp
Message-ID: <>

* Raymond Toy <>
| But aren't some of the things they claim also wrong:
| 	However, Common Lisp has several drawbacks:
| 	Its performance is slow (as compared to a C++ program);

  my experience is that well-written Common Lisp is more space and time
  efficient than well-written C++, but not so with well-written C in which
  you basically hard-code every assumption and thereby win big.  enter a
  lot of dynamic memory, and C also loses to Common Lisp, not the least
  because malloc/free are hopelessly ineffecient in both time and space.

| 	it does not interface well to tools and applications in commercial
| 	environments (e.g., to C++ and CORBA);

  I'm sure this was true once.

| 	and it fails to incorporate recent object system trends
| 	(e.g., collections, iterators, and parameterized types).

  these are specific implementations of "inventions" required in C++
  because it doesn't have what people _actually_ need.

| 	As a result, customer demand and vendor support for Lisp is
| 	declining, creating yet another reason to abandon Lisp.

  I think "creating" here should be read literally, they literally had to
  create a reason to abandon Lisp...

| Lisp has CORBA right?  

  there's the ILU, and Allegro CL ORBlink.

| I also think interfacing anything to C++ except C++ is quite hard, so
| that's a moot point.

  well, Allegro CL does that, too.

| Doesn't lisp have collections and iterators (of some sort)?

  we have mapping functions, which are much more powerful than iterators.
  collections?  what's a list if _not_ a collection?

| I'm not sure about "parameterized types".

  I see STRING in (coerce <whatever> 'string) as a paremeterized type.

  there are still some valid reasons to reject Common Lisp.  I find it
  rather curious that people don't use them.

  Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
  Julk, August, September, October, November, December.