6 ms·

I don't understand this. Are you saying that SLIME/SLY debugging of SBCL in Emacs is "basically a CLI tool running separately in a window"? It is arguably the m

by macmac 3y ago

I don't understand this. Are you saying that SLIME/SLY debugging of SBCL in Emacs is "basically a CLI tool running separately in a window"? It is arguably the most powerful debugging experience available for any programming language. There is ton of documentation and tutorials available and it is as far from janky as you can possibly get.

jonathankoren 3y ago
It’s a janky 80% solution. Saying that you just have to watch a bunch of tutorials betrays just how janky it is.
- macmac 3y ago
  It what way is it janky exactly? I mean what normal debugger functionality is missing/broken? Or do you find it hard to discover?
  - jonathankoren 3y ago
    I would think it's obvious. Look at any commercially developed debugger for any language. Xcode. Eclipse. IntelliJ, VSCode. AllegroCL. Now compare that Emacs + anything. Atom/Pulsar + anything. Vi + anything. Just look at the screenshots. What's missing? Literally everything is missing, because it's just a CLI in a window. Want to add a breakpoint? Type in the window. Want to know how many threads are running? Type in the window. Want to pause a thread? Type in the window. Want to inspect a variable? Type in the window. Want to drill down through a complex data structure? Type that 50 character line correct in one go bitch. By god! Don't you dare complain! The irony of course is that all of these commercial products are using the exact same debugging infrastructure of the OSS counterparts. It's just that one group finished the job, and the other doesn't bother to finish the job.
    - _19qg 3y ago
      Obviously you have never used it.
  - HexDecOctBin 3y ago
    I mostly have experience with C/C++ but have done some CL, and I agree with GP. Check out the debugging UX (not the performance :) of Visual Studio. More specifically, see how intuitive and discoverable it is for beginners. For example, in CL debugging, how would I reliably set a breakpoint at some nested expression in a function body, run to it, and step through the code "expr-by-expr" while verifying a bunch of values in a watch window? In VS, it's one click to set breatpoint, one keypress or two clicks to run to it, one click to step to next line, and one double click and typing an expression to set up a watch that would show updated value of that expression every time execution pauses while taking care of scoping, etc.
    - aidenn0 3y ago
      For background: I learned C 6 years before I first started learning Lisp; I used every version of Visual Studio starting with 6.0 through .net 200X (I'd have to pull out my CDs to see which the last version I used was). Prior to that I used Borland's C++ IDE. > For example, in CL debugging, how would I reliably set a breakpoint at some nested expression in a function body, run to it, and step through the code "expr-by-expr" while verifying a bunch of values in a watch window? I ... don't ever do this when debugging lisp? Sly has support for setting breakpoints, but I'm used to adding (break) expressions; the "breakdot on the side" doesn't work as well with Lisp as C (With idiomatic C you very rarely want to set a breakpoint in the middle of a line, and it's rare for a single statement to be more than 2-ish lines; I should also note that IIRC setting breakpoints in the middle of a line in VS was not the best UX). Sly has a keyboard shortcut for stepping, but I don't have it memorized because I hardly ever use it. Conversely its F10/F11 in VS, which I still remember despite not having used Visual Studio for at least a decade, since I did it a lot! Conversely, I have the shortcuts for recompile the single file I'm in and recompile the single function I'm in memorized, since I use those all the time when debugging. I believe VS added hot-patching functions at some point near the end of my usage, but it wasn't part of my workflow like it is with Lisp. (The lack of) watch windows is a deficiency in Sly. While you can view all locals in the current stack-frame while debugging, it doesn't let you watch arbitrary expressions, and if you have too many locals it can be hard to focus on what you want. I should point out stickers (C-c C-s C-s) let you trace evaluations of arbitrary subexpressions, and this has some overlap with how watchpoints are used in VS.
PuercoPop 3y ago
> is arguably the most powerful debugging experience available for any programming language. The sly debugger is better than most debuggers, but calling it the most powerful debugging experience is a stretch. Just try the debuger in a Smalltalk implementation (Squeak/Pharo/Cuis)

by macmac 3y ago

jonathankoren 3y ago

It’s a janky 80% solution. Saying that you just have to watch a bunch of tutorials betrays just how janky it is.

macmac 3y ago
It what way is it janky exactly? I mean what normal debugger functionality is missing/broken? Or do you find it hard to discover?
- jonathankoren 3y ago
  I would think it's obvious. Look at any commercially developed debugger for any language. Xcode. Eclipse. IntelliJ, VSCode. AllegroCL. Now compare that Emacs + anything. Atom/Pulsar + anything. Vi + anything. Just look at the screenshots. What's missing? Literally everything is missing, because it's just a CLI in a window. Want to add a breakpoint? Type in the window. Want to know how many threads are running? Type in the window. Want to pause a thread? Type in the window. Want to inspect a variable? Type in the window. Want to drill down through a complex data structure? Type that 50 character line correct in one go bitch. By god! Don't you dare complain! The irony of course is that all of these commercial products are using the exact same debugging infrastructure of the OSS counterparts. It's just that one group finished the job, and the other doesn't bother to finish the job.
  - _19qg 3y ago
    Obviously you have never used it.
- HexDecOctBin 3y ago
  I mostly have experience with C/C++ but have done some CL, and I agree with GP. Check out the debugging UX (not the performance :) of Visual Studio. More specifically, see how intuitive and discoverable it is for beginners. For example, in CL debugging, how would I reliably set a breakpoint at some nested expression in a function body, run to it, and step through the code "expr-by-expr" while verifying a bunch of values in a watch window? In VS, it's one click to set breatpoint, one keypress or two clicks to run to it, one click to step to next line, and one double click and typing an expression to set up a watch that would show updated value of that expression every time execution pauses while taking care of scoping, etc.
  - aidenn0 3y ago
    For background: I learned C 6 years before I first started learning Lisp; I used every version of Visual Studio starting with 6.0 through .net 200X (I'd have to pull out my CDs to see which the last version I used was). Prior to that I used Borland's C++ IDE. > For example, in CL debugging, how would I reliably set a breakpoint at some nested expression in a function body, run to it, and step through the code "expr-by-expr" while verifying a bunch of values in a watch window? I ... don't ever do this when debugging lisp? Sly has support for setting breakpoints, but I'm used to adding (break) expressions; the "breakdot on the side" doesn't work as well with Lisp as C (With idiomatic C you very rarely want to set a breakpoint in the middle of a line, and it's rare for a single statement to be more than 2-ish lines; I should also note that IIRC setting breakpoints in the middle of a line in VS was not the best UX). Sly has a keyboard shortcut for stepping, but I don't have it memorized because I hardly ever use it. Conversely its F10/F11 in VS, which I still remember despite not having used Visual Studio for at least a decade, since I did it a lot! Conversely, I have the shortcuts for recompile the single file I'm in and recompile the single function I'm in memorized, since I use those all the time when debugging. I believe VS added hot-patching functions at some point near the end of my usage, but it wasn't part of my workflow like it is with Lisp. (The lack of) watch windows is a deficiency in Sly. While you can view all locals in the current stack-frame while debugging, it doesn't let you watch arbitrary expressions, and if you have too many locals it can be hard to focus on what you want. I should point out stickers (C-c C-s C-s) let you trace evaluations of arbitrary subexpressions, and this has some overlap with how watchpoints are used in VS.

PuercoPop 3y ago

> is arguably the most powerful debugging experience available for any programming language. The sly debugger is better than most debuggers, but calling it the most powerful debugging experience is a stretch. Just try the debuger in a Smalltalk implementation (Squeak/Pharo/Cuis)