> The problem with Lisp (I think I can claim to be an expert) is that
> it hides so much of the execution and implementation model that
> most Lisp programmers were hopeless when it came to figuring out
> performance. Because Lisp manages storage, programmers were wanton
> in their use of memory; because Lisp hides the implementation of
> common operations and the users didn't have to know how fast anything
> was, they would write abysmally awful programs.
I general, you are right. The philosophy there is:
C programmers think that memory management is so important that
they *can't* let the system manage it. LISP programmers think that
memory management is so important that they know they *must* let
the system manage it.
> Often the more the language and system hide in the interest
> of reducing complexity, the more problems you have when it
> comes to performance.
This really depends on the kind of program. For example, Visual
Basic (blech.) is very high-level, but performance of VB apps
is, in general, quite good. I think the trick is choosing the
right level of abstraction in interpreted languages, just as it
is in remote systems. In such systems, the higher-level language
is used as a component model for a lower-level implementation
language.
Anyway, some lisp systems (and more than a few modern functional
programming languages) have *excellent* performance
characteristics.
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 08:04:36 PDT