6 ms·
Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. While Lisp gets a
by reikonomusha 8y ago
Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. While Lisp gets a lot of flak for basically (up to a few daring power-user exceptions) requiring Emacs, SLIME/SLY [1,2] are environments that will make you feel closer to your program than you get in other environments, including graphical IDEs.
Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else’s!) will break, and it will break often, and you’ll get launched into an interactive debugger. But it’s friendly, not requiring a completely separate, foreign toolchain, and much of the functionality works regardless of which editors/IDEs you’re using (though Emacs makes the experience much more ergonomic).
I think this is perhaps a bigger selling point of Common Lisp than all the great, oft-quoted things like metaprogramming.
[1] https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/
[2] https://github.com/joaotavora/sly https://github.com/joaotavora/sly
- kadenshep 8y agoI've loved this aspect of CL. I often repeat a self-quote of mine (somewhat patronizingly) to my teams. Often times, it's not necessarily how something works, but how well it breaks. Things will break, so engineer for it. You'll be happy, the team will be happy, and the business will be happy. Debugging and error handling are first class activities. Building a thoughtful, "well engineered" tool chain around these activities is the mark of a great platform (and the developers behind it), in my opinion.
- ranit 8y ago> Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp A bit of nitpicking: It is anything but "extraordinarily", it is a completely ordinary activity.
- stcredzero 8y agoDebugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. Smalltalk is something like the ultimate debugger. The advanced Smalltalk coders would often do most of their coding in the debugger. (It's very easy to unwind the stack a few places, then resume execution.) The VisualWorks debugger was so nimble, people would put expressions to be executed and debugged into code comments! (The debugger would execute the code in the context in which it was evaluated, so this could be absolutely awesome.) Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else’s!) will break, and it will break often, and you’ll get launched into an interactive debugger. One of the most frequent demos we did in Smalltalk, was to write some empty scaffold methods, launch into an exception, then fill in everything in the debugger until the system was complete.
- ben509 8y agoI think direct language support for "missing code here!" is a brilliant idea. Even when you have types and documentation, you often need to dummy check that values you'll get called with are what you expect.
- corysama 8y agoI've heard Smalltalkers tell tales of starting an empty project by just hitting "Run", letting the debugger take exception to that fact that there is no startup function, then start typing code as it becomes necessary to proceed.
- stcredzero 8y agoThat's what I just wrote!
- traviscj 8y agoI read the GP as saying “you don’t even need to create the scaffold methods” described in your post.