Re: Lisp considered unfinished

["David B. Lamkins" <dlamkins@teleport.com>]

doner@aero.org (John Doner) wrote:
[...]
>Accessibility: Good C compilers are available, are cheap, and fit
>on relatively small student-owned machines.  Having your own system
>on your own machine is a big plus for anyone learning a language.
>It isn't a requirement, but it helps.

cost(Lisp environment) < cost(C environment) : usually true.

size(Lisp environment) < size(C environment) : debatable.

On my Mac, MCL 2.0 takes up 5.7 MB, fully loaded.  Symantec THINK C++ 7.0
takes up 15.5 MB of disk, fully loaded.  MCL will run comfortably in 3-5 MB
of physical memory.  THINK C++ requires 8-12 MB.

At work, the ratios are similar when comparing ALC/Windows 2.0 and MS VC++ 2.1.

>Debugging: Most Lisps have pretty serviceable debugging tools.  But
>what if your code breaks something at a low level?  It's pretty
>easy to tell what piece of C source some assembly code corresponds
>to, but not so for Lisp.

This may be an issue of familiarity with language implementation issues, as
suggested earlier in your post (not quoted here).  A Lisp disassembly, at
lower optimization levels, tends to name a lot of primitive operations that
pretty clearly indicate what's going on.

>  And there are other difficult situations:
>I've been scratching my head for a while over one where the
>compiler chokes on code produced by several layers of interacting
>macros.  It is bewildering trying to figure out where this code
>originally came from!

How about macroexpand-1?

Dave
http://www.teleport.com/~dlamkins
---
CPU Cycles: Use them now, while you still have them.