From ... From: Erik Naggum Subject: Re: garnet performance issues Date: 1999/02/12 Message-ID: <3127777371842834@naggum.no>#1/1 X-Deja-AN: 443465913 References: <8790e57nju.fsf@soggy.deldotd.com> <4naeyky0bd.fsf@rtp.ericsson.se> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * 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 '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. #:Erik -- Y2K conversion simplified: Januark, Februark, March, April, Mak, June, Julk, August, September, October, November, December.