Subject: Re: Are there any LISP development systems that are VC, or other GUI IDE  like?
From: Erik Naggum <erik@naggum.no>
Date: 2000/02/09
Newsgroups: comp.lang.lisp
Message-ID: <3159124272806425@naggum.no>

* Robert Posey <muddy@raytheon.com>
| While the interpreted, or incremental compiled nature of LISP is growing on 
| me I still find all the systems I have used to be a pain.

  Common Lisp systems provide more powerful hammers.  if you are used to
  C/C++, you are numbed to the pain of hitting your thumb with a puny
  hammer (at least conceptually), but now that you hit your thumb that much
  harder, it hurts again, that much more.  the solution is to quit hitting
  your thumb, not to pad your thumb or stifle the hammer's power.

  at some point in time, you learned the C/C++ way, without reference to
  much anything, right?  at this point in time, you should endeavor to
  learn the Common Lisp way, without reference to much anything.  study how
  people experience in the Common Lisp way do it.  do not attempt to use
  your C++ expertise in Common Lisp.  what works for C/C++ has evolved over
  time to be the least painful and/or most efficient.  what governs
  qualities such as "least painful" and "most efficient", however, are
  vastly different for Common Lisp.  it's that simple, really.  _after_ you
  have established rapport with your environment, you should compare them
  in terms of what you can accomplish in each with how much work, not in
  terms of how well a later experience emulates some environment that just
  happened to be a prior experience.

  most people, when they have learned something, tend to think in extremely
  concrete terms about what they are doing.  they think they click on menu
  bars, drag an object, double-click on icons, etc.  they _don't_ think in
  terms of the operation that said physical activity causes to take place,
  even though that is why they perform these physical actions.  so when
  they want to perform that operation in a new environment, they completely
  _ignore_ the fact that they once had to associate the operation with
  these actions, and now request the actions, as if the action and the
  operation were the same.  well, they very obviously aren't, and if they
  think that way, they failed to learn what they were doing in a productive
  and efficient way -- they instead learned to parrot actions.  the sooner
  human beings get out of this modus operandi and become _thinking_ beings,
  the better, and if it hurts a little to get out of parrot mode, so be it.
  most everything worth doing is associated with effort and some pain.

  so, to answer your real question: no, we don't debug functions the same
  way in Common Lisp as in static languages.

  inserting code to get the equivalent of (conditional) breakpoints isn't a
  problem, btw, since you can edit and recompile a function in seconds, and
  if you have to do it with a mouse click, teach Emacs to insert "(break)"
  and recompile the function upon a mouse click.  I fail to see the value
  of such a user interface function, but, hey, it's been years since I set
  a breakpoint in any C code, too, precisely because I'm much more used to
  the Common Lisp way, and even the best C debuggers _suck_, so I spend a
  little more time thinking about the code I write and experimenting in --
  you guessed it, Common Lisp -- before I commit the design to C, almost as
  if by hand-compiling code in a real language into machine instructions
  burned into an EEPROM or something equivalently hardware-like and way
  cumbersome to deal with.  odd as it may seem, writing bug-free C code is
  really a breeze once you have come to appreciate and think in Common Lisp.

#:Erik