5 ms·

I’ve tried SBCL in Atom/Pulsar and Emacs. I found the debugger confusing as hell. The whole thing felt super janky compared to a properly integrated debugger.

I’ve tried SBCL in Atom/Pulsar and Emacs. I found the debugger confusing as hell. The whole thing felt super janky compared to a properly integrated debugger. What I want — what I really really want — is an Allegro CL experience. Unfortunately, nothing provides it, nor does it look like anyone has any interest in providing such an experience. This isn’t just a CL problem. Janky debugger integration is widespread. It’s the pathetic that only commercial developers provide a polished debugging experience. Everyone else is satisfied with a basically a CLI tool running separately in a window. That’s like. 80% solution. We can do better. We should do better.

pasc1878 3y ago
There is an exception to only commercial developers provide a polished debugging environment and that is the various non GNU open source Smalltalks. Eclipse can also produce reasonable debugging for Java at least. But yes other than that poor debuggers do limit the choice of languages. Unfortunately PHP is better served than most interesting languages.
- pjmlp 3y ago
  Squeak is basically a port of the original Xerox PARC Smalltalk-80 image into a more portable implementation from Xerox folks themselves, Pharo was originally a Squeak fork. Eclipe was born as a rewrite from Visual Age for Smalltalk into Java. See the difference?
fuzztester 3y ago
interesting that you say this. have you also tried out Franz Lisp? it is another commercial one.
- jonathankoren 3y ago
  Franz was too expensive :) Allegro had an academic license.
  - fuzztester 3y ago
    Okay. I think both you and I may have made a mistake about the product names. (I just corrected mine, which was in this same comment. Corrected info below.) I had tried out Allegro Common Lisp (which is from Franz, Inc.) and LispWorks Common Lisp, some years ago. Maybe sometime after Peter Seibel's book Practical Common Lisp came out. I had also tried out GNU Lisp at some point.
    - jonathankoren 3y ago
      Yeah. There are two. I definitely used Allegro, which apparently is from Franz. I remember that the other commercial one was very expensive. It’s been like 20 years ago. :)
      - _19qg 3y ago
        There are two companies: Franz Inc. and LispWorks Ltd. The Lisp development product of Franz Inc. is Allegro CL. https://franz.com/products/allegro-common-lisp/ https://franz.com/products/allegro-common-lisp/ The Lisp development product of LispWorks Ltd. is LispWorks. https://www.lispworks.com/products/lispworks.html https://www.lispworks.com/products/lispworks.html Both are kind of expensive. Both offer also academic licenses. "Franz Lisp" does not exist as a product since the 80s. Both Allegro CL and LispWorks are sold since the mid/end 80s and are still being maintained and sold.
vindarel 3y ago
Do you say so for Emacs and Slime's debugger too? It's certainly weird at first, but powerful and integrated. Although it isn't graphical like LispWorks' (and probably Allegro's), so I agree it could be even better. (for readers: Slime's debugger is not a separate CLI tool running in a window) (ps: see slime-breakpoints for a nice graphical addition: https://github.com/mmontone/slime-breakpoints https://github.com/mmontone/slime-breakpoints)
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.
    - 3y ago
Jach 3y ago
I mostly agree, though I find Allegro and LispWorks severely lacking in areas too. The companies themselves don't seem to care much about their IDEs. Certainly not in the way JetBrains cares about IntelliJ. Tucked away in the McCLIM project is Clouseau, which you can quickload and use as a normal user: https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Clouseau https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Cl... One small cool thing it does is if you inspect a complex number it will also draw a little x-y graph with its vector representation. (Though trying it out again just now it's overlapping with the text... maybe I should file a bug, but I've only now just learned they moved off github, and I'm not going to make a codeberg account. Friction wins this round.) It does take a while to first compile and load all the dependencies, especially 3bz, another weakness of at least our free Lisps; AFAIK there's still no equivalent of make -j for compiling systems. I'm a happy vim user (though there is some jank with slimv, admittedly, but it's mostly prevalent around multiple thread situations) and setup the command ,ci to call my own clouseau-inspect function; it just inspects a symbol with clouseau instead of slimv's inspector. Also have a janky watch/unwatch pair of functions that just refreshes the inspector every second. (https://github.com/Jach/dots/blob/master/.sbclrc#L113 https://github.com/Jach/dots/blob/master/.sbclrc#L113 if curious, some other junk in .swank.lisp and .vimrc too, and there's https://github.com/dense-analysis/ale/issues/4061 https://github.com/dense-analysis/ale/issues/4061 to call sblint on your project...) But more graphical tools like this are what I hope to one day see more of and are how the free Lisps can close the gap in this area with the commercial Lisps. I believe there's not much Allegro can do that poking around SBCL can't do, but for many things it's just nicer to have a GUI. Want to explore all the symbols and values in a package? Easy enough to script that, but not as nice as just having a table of symbols, and even nicer if you can set watches on some of them, or even set conditional breakpoints on value changes. None of the tools need to be tightly integrated with a single IDE either, because all the stuff necessary to debug Lisp is in the running Lisp itself. It's just that the GUI situation continues to suck. LSP has gotten more popular with other languages and editors, sometimes I wonder if the acronym was made as an inside joke because it's basically how Lisp + Slime/Swank have worked...
- jonathankoren 3y ago
  Exactly. All the parts are there. Just no one goes beyond the bare minimum of polish.

pasc1878 3y ago

There is an exception to only commercial developers provide a polished debugging environment and that is the various non GNU open source Smalltalks. Eclipse can also produce reasonable debugging for Java at least. But yes other than that poor debuggers do limit the choice of languages. Unfortunately PHP is better served than most interesting languages.

pjmlp 3y ago
Squeak is basically a port of the original Xerox PARC Smalltalk-80 image into a more portable implementation from Xerox folks themselves, Pharo was originally a Squeak fork. Eclipe was born as a rewrite from Visual Age for Smalltalk into Java. See the difference?

fuzztester 3y ago

interesting that you say this. have you also tried out Franz Lisp? it is another commercial one.

jonathankoren 3y ago
Franz was too expensive :) Allegro had an academic license.
- fuzztester 3y ago
  Okay. I think both you and I may have made a mistake about the product names. (I just corrected mine, which was in this same comment. Corrected info below.) I had tried out Allegro Common Lisp (which is from Franz, Inc.) and LispWorks Common Lisp, some years ago. Maybe sometime after Peter Seibel's book Practical Common Lisp came out. I had also tried out GNU Lisp at some point.
  - jonathankoren 3y ago
    Yeah. There are two. I definitely used Allegro, which apparently is from Franz. I remember that the other commercial one was very expensive. It’s been like 20 years ago. :)
    - _19qg 3y ago
      There are two companies: Franz Inc. and LispWorks Ltd. The Lisp development product of Franz Inc. is Allegro CL. https://franz.com/products/allegro-common-lisp/ https://franz.com/products/allegro-common-lisp/ The Lisp development product of LispWorks Ltd. is LispWorks. https://www.lispworks.com/products/lispworks.html https://www.lispworks.com/products/lispworks.html Both are kind of expensive. Both offer also academic licenses. "Franz Lisp" does not exist as a product since the 80s. Both Allegro CL and LispWorks are sold since the mid/end 80s and are still being maintained and sold.

vindarel 3y ago

Do you say so for Emacs and Slime's debugger too? It's certainly weird at first, but powerful and integrated. Although it isn't graphical like LispWorks' (and probably Allegro's), so I agree it could be even better. (for readers: Slime's debugger is not a separate CLI tool running in a window) (ps: see slime-breakpoints for a nice graphical addition: https://github.com/mmontone/slime-breakpoints https://github.com/mmontone/slime-breakpoints)

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.
  - 3y ago

Jach 3y ago

I mostly agree, though I find Allegro and LispWorks severely lacking in areas too. The companies themselves don't seem to care much about their IDEs. Certainly not in the way JetBrains cares about IntelliJ. Tucked away in the McCLIM project is Clouseau, which you can quickload and use as a normal user: https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Clouseau https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Cl... One small cool thing it does is if you inspect a complex number it will also draw a little x-y graph with its vector representation. (Though trying it out again just now it's overlapping with the text... maybe I should file a bug, but I've only now just learned they moved off github, and I'm not going to make a codeberg account. Friction wins this round.) It does take a while to first compile and load all the dependencies, especially 3bz, another weakness of at least our free Lisps; AFAIK there's still no equivalent of make -j for compiling systems. I'm a happy vim user (though there is some jank with slimv, admittedly, but it's mostly prevalent around multiple thread situations) and setup the command ,ci to call my own clouseau-inspect function; it just inspects a symbol with clouseau instead of slimv's inspector. Also have a janky watch/unwatch pair of functions that just refreshes the inspector every second. (https://github.com/Jach/dots/blob/master/.sbclrc#L113 https://github.com/Jach/dots/blob/master/.sbclrc#L113 if curious, some other junk in .swank.lisp and .vimrc too, and there's https://github.com/dense-analysis/ale/issues/4061 https://github.com/dense-analysis/ale/issues/4061 to call sblint on your project...) But more graphical tools like this are what I hope to one day see more of and are how the free Lisps can close the gap in this area with the commercial Lisps. I believe there's not much Allegro can do that poking around SBCL can't do, but for many things it's just nicer to have a GUI. Want to explore all the symbols and values in a package? Easy enough to script that, but not as nice as just having a table of symbols, and even nicer if you can set watches on some of them, or even set conditional breakpoints on value changes. None of the tools need to be tightly integrated with a single IDE either, because all the stuff necessary to debug Lisp is in the running Lisp itself. It's just that the GUI situation continues to suck. LSP has gotten more popular with other languages and editors, sometimes I wonder if the acronym was made as an inside joke because it's basically how Lisp + Slime/Swank have worked...

jonathankoren 3y ago
Exactly. All the parts are there. Just no one goes beyond the bare minimum of polish.