4 ms·

> In CL/SLIME, you add `(break)` to the code Having to modify code to add/remove breakpoints is pretty much the definition of jankiness. Can Emacs+SBCL show a

> In CL/SLIME, you add `(break)` to the code Having to modify code to add/remove breakpoints is pretty much the definition of jankiness. Can Emacs+SBCL show a list of all breakpoints, for example? > This is a common complaint about CL, but my experience is that the utility of debuggers is vastly over-stated. I disagree. A debugger gives you insight into the state of the program. It makes no sense to burn neural cycles trying to track program's state manually when a debugger can visualise it in multiple views and forms. Frankly, during development, I always run my code in a debugger, just to be able to confirm my assumptions on a granular level whenever I want to. > the “repl-driven development” paradigm of CL In my experience, trying to substitute a proper debugger with REPL leads to unnecessarily small functions, which then lead to very deep call stacks and undocumented assumptions about pre- and post-conditions of all those tiny functions. However, CL is specially bad about this anyway, since every `let` binding adds a new nesting, making long linear functions unreadable (either due to deep nesting, or due to predeclaring all variable as in ANSI C). Scheme with its `define` is much better in this regard.

medo-bear 3y ago
Since I dont use VS Code I'm not sure if I follow but most of these things you describe are in fact available, at least with Emacs+SLY (Common Lispers either use Emacs+SLIME or Emacs+SLY). What you call "non-janky" break points are referred to as Stickers in SLY, which on the whole seem to me a far more advanced idea than what you say VS offers. See https://joaotavora.github.io/sly/#Debugger https://joaotavora.github.io/sly/#Debugger
- HexDecOctBin 3y ago
  I am not talking about VS Code, but Visual Studio (or any other visual debugger from the last 30 years). Sly's UI seems to be similar to that of GDB, which is exactly what I am talking about. I would suggest trying out and comparing GDB and one of its numerous GUI frontends to understand why a GUI with multiple views displayed simultaneously (i.e., you can keep track of different parts of state on different parts of screen) and automatically (i.e., display doesn't require interaction) improves debugging experience.
  - medo-bear 3y ago
    The point I was making was that Emacs+SLY solution has nonintrusive debugging annotations. As regards windows and gui, I also dont understand. I can certainly have multiple windows displayed in Emacs, even in a tty terminal. What buffer each of those windows serves is up to me. Certainly I can have each state sent to a different buffer. One of the things I personally value about Emacs is that I don't have to run it in some Windowing gui system to get any of the supposed benefits. Heck I can even use a mouse to adjust window sizes in just my tty. I dont get what GUI gives you except a higher overhead
    - jonathankoren 3y ago
      You should sit this one out. You already said you aren't familiar with the systems being discussed.
      - medo-bear 3y ago
        Lol no worries hero :) I am unfamiliar in the sense that I cant be bothered to actually try it. However everything I said applies to what is being described herein https://learn.microsoft.com/en-us/visualstudio/debugger/debugger-feature-tour?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/debu... There is no feature here that is not available for debugging Common Lisp in Emacs, which has much more powerful debugging tools, and with less overhead https://lispcookbook.github.io/cl-cookbook/debugging.html https://lispcookbook.github.io/cl-cookbook/debugging.html
      - lispm 3y ago
        For starters: GNU Emacs is not providing a Command Line Interface, CLI.
        medo-bear 3y ago
        Exactly. The following demonstration on GDB in Emacs looks pretty good to me. In fact, it can do this even in tty, no GUI required. https://m.youtube.com/watch?v=aNTFDq3e2Qo https://m.youtube.com/watch?v=aNTFDq3e2Qo
lispm 3y ago
> Frankly, during development, I always run my code in a debugger For many Common Lisp implementations you don't need that. The debugger & source interpreter & compiler & break loops are always available. One also does not need to "instrument" code for a debugger. > In my experience, trying to substitute a proper debugger with REPL leads to unnecessarily small functions That makes no sense. The REPL includes a debugger and does not enforce a function size. You can call&debug functions of any size from a REPL. Stack traces can be detailed or overview. From within the REPL, which in case of break is a break-loop, which is a REPL with added debug commands. > undocumented assumptions about pre- and post-conditions of all those tiny functions The idea of tiny functions is made up by you. Common Lisp's debugging tools don't enforce tiny functions. Just the opposite, many CL code bases have large functions, which are also even larger after macro expansion. pre- and post conditions can be explicit parts of Common Lisp code, since it has :before, :around and :after methods. > every `let` binding adds a new nesting Lisp uses nested lists. That's one thing to learn from day one when programming in Lisp. Nested code shows indented blocks. > or due to predeclaring all variable as in ANSI C) Not predeclaring variables is bad practice anyway. > Scheme with its `define` is much better in this regard. No, Scheme's "define" has to be at the top of a block, according to Scheme standards.

medo-bear 3y ago

Since I dont use VS Code I'm not sure if I follow but most of these things you describe are in fact available, at least with Emacs+SLY (Common Lispers either use Emacs+SLIME or Emacs+SLY). What you call "non-janky" break points are referred to as Stickers in SLY, which on the whole seem to me a far more advanced idea than what you say VS offers. See https://joaotavora.github.io/sly/#Debugger https://joaotavora.github.io/sly/#Debugger

HexDecOctBin 3y ago
I am not talking about VS Code, but Visual Studio (or any other visual debugger from the last 30 years). Sly's UI seems to be similar to that of GDB, which is exactly what I am talking about. I would suggest trying out and comparing GDB and one of its numerous GUI frontends to understand why a GUI with multiple views displayed simultaneously (i.e., you can keep track of different parts of state on different parts of screen) and automatically (i.e., display doesn't require interaction) improves debugging experience.
- medo-bear 3y ago
  The point I was making was that Emacs+SLY solution has nonintrusive debugging annotations. As regards windows and gui, I also dont understand. I can certainly have multiple windows displayed in Emacs, even in a tty terminal. What buffer each of those windows serves is up to me. Certainly I can have each state sent to a different buffer. One of the things I personally value about Emacs is that I don't have to run it in some Windowing gui system to get any of the supposed benefits. Heck I can even use a mouse to adjust window sizes in just my tty. I dont get what GUI gives you except a higher overhead
  - jonathankoren 3y ago
    You should sit this one out. You already said you aren't familiar with the systems being discussed.
    - medo-bear 3y ago
      Lol no worries hero :) I am unfamiliar in the sense that I cant be bothered to actually try it. However everything I said applies to what is being described herein https://learn.microsoft.com/en-us/visualstudio/debugger/debugger-feature-tour?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/debu... There is no feature here that is not available for debugging Common Lisp in Emacs, which has much more powerful debugging tools, and with less overhead https://lispcookbook.github.io/cl-cookbook/debugging.html https://lispcookbook.github.io/cl-cookbook/debugging.html
    - lispm 3y ago
      For starters: GNU Emacs is not providing a Command Line Interface, CLI.
      - medo-bear 3y ago
        Exactly. The following demonstration on GDB in Emacs looks pretty good to me. In fact, it can do this even in tty, no GUI required. https://m.youtube.com/watch?v=aNTFDq3e2Qo https://m.youtube.com/watch?v=aNTFDq3e2Qo

lispm 3y ago

> Frankly, during development, I always run my code in a debugger For many Common Lisp implementations you don't need that. The debugger & source interpreter & compiler & break loops are always available. One also does not need to "instrument" code for a debugger. > In my experience, trying to substitute a proper debugger with REPL leads to unnecessarily small functions That makes no sense. The REPL includes a debugger and does not enforce a function size. You can call&debug functions of any size from a REPL. Stack traces can be detailed or overview. From within the REPL, which in case of break is a break-loop, which is a REPL with added debug commands. > undocumented assumptions about pre- and post-conditions of all those tiny functions The idea of tiny functions is made up by you. Common Lisp's debugging tools don't enforce tiny functions. Just the opposite, many CL code bases have large functions, which are also even larger after macro expansion. pre- and post conditions can be explicit parts of Common Lisp code, since it has :before, :around and :after methods. > every `let` binding adds a new nesting Lisp uses nested lists. That's one thing to learn from day one when programming in Lisp. Nested code shows indented blocks. > or due to predeclaring all variable as in ANSI C) Not predeclaring variables is bad practice anyway. > Scheme with its `define` is much better in this regard. No, Scheme's "define" has to be at the top of a block, according to Scheme standards.