From ... From: Erik Naggum Subject: Re: Are there any LISP development systems that are VC, or other GUI IDE like? Date: 2000/02/09 Message-ID: <3159124272806425@naggum.no>#1/1 X-Deja-AN: 583861020 References: <38A09051.93D0BC3@raytheon.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 950135659 9210 195.0.192.66 (9 Feb 2000 22:34:19 GMT) Organization: Naggum Software; +47 8800 8879 or +1 510 435 8604; fax: +47 2210 9077; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 9 Feb 2000 22:34:19 GMT Newsgroups: comp.lang.lisp * Robert Posey | 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