4 ms·

First step would be to support SLIME in editors other than Emacs.

by tocariimaa 2y ago

kagevf 2y ago
vim has 2 implementations of slime. Lem is a new editor written in Common Lisp that has slime "built-in".
- tocariimaa 2y ago
  > vim has 2 implementations of slime. Which are both buggy and one of them is abandoned. > Lem is a new editor written in Common Lisp that has slime "built-in". "Lem" is not (neo)vim, has Emacs RSI bindings and even if by some chance it included some "vi mode", it would simply be an emulation, not an actual vi editor. Same issue with Emacs using "evil mode".
  - kagevf 2y ago
    > even if by some chance it included some "vi mode", it would simply be an emulation, not an actual vi editor Lem supports vim key bindings, according to its README. btw, I don't have any issues with emacs keybindings, but I chuckled at the "Emacs RSI bindings" :) In fact, I think vim keybindings are superior for editing - you can't beat hitting "." to repeat an action - but after using emacs for ~5 years I find myself in it a lot more than I expected when I started using it. The whole thing with key bindings is that for whichever one(s) you use your muscle memory catches up.
nickelpro 2y ago
I despise SLIME. It made perfect sense in 2003 and was way ahead of the game compared to every other language for decades, but today we have the language server protocol and every effort should be made to support that instead. Anecdotally, the AliveLSP works fine although it suffers from the same "Why would you want a standalone program? Load it into the REPL" problems I derided in response to the parent.
- anonzzzies 2y ago
  I guess SLIME just works well for most as I would say it is still ahead every time I see python devs using their 'great tools' including a lsp in pain. I like a lsp where, during development, my core runs and I can see live feedback of it running when I make changes. Kind of like, you know, an image. That does not say you need to depend on that image outside dev (like an lsp, reset it when you reload a project, quit the editor etc), but during dev it's just superior imho.
  - nickelpro 2y ago
    Ya, this is the core of the disagreement that I would run into with the old school lispers. I see it, I do, my third eye is open. I get the entire flow that the interactive development environment brings to the table and how it is infinitely superior than what existed in every other language for decades. But I don't like it more than the modern tooling. That's pure personal preference. I don't like this weird stateful thing hanging out in the background of my dev environment. I don't find value in sending random expressions into the weird stateful blob. If I wanted to drop into a debugger, I'll ask, don't hijack my stacktraces. I write tight test loops, modify my code, run the tests from scratch in the same one-key press the lispers use to evaluate their s-expressions. I don't need to go back and verify my build or application works from scratch, it never breaks, I'm constantly rebuilding. I would run into situations not infrequently where some post-doc wasn't quite sure how they achieved the state they did in the image, had a bug, but no tests to reproduce the bug or anything else. Maddening. An anti-pattern I never saw accomplished to the same degree with the Python boys (not to say Jupyter Notebooks aren't their own stateful fucking mad house of bad software engineering).
    - anonzzzies 2y ago
      I still see those as different things; if there is no 'state' besides running your code as in files as you edit it and it kills the image when you stop, how did you get to : > how they achieved the state they did in the image Because in my view, there is no image beyond your debug session. But yeah, it would be nice to sit together at a meetup and you showing me what's so great about this modern tooling, because the modern tooling is terrible in my opinion. Sure, a debugger is ok-ish, when it works (which is sketchy at best if I see my friends trying to debug nextjs/react in vscode and breakpoints not hitting or in the wrong place etc etc or simply completely not working etc, but let's say it works perfectly); you still cannot just quickly test different path etc. I have been programming for well over 40 years and I did lisp/prolog in uni, then I went to the usual, Java, C#, JS/TS, Python, C/C++, Pascal/Delphi etc before trying lisp (&prolog) again and finding the modern tooling fairly lacking and annoying. What you do, as you describe it, has simply nothing to do with modern test tools; you could do TDD with tight test loops in 1993 and it was a good way to do things. There is nothing in Coomon Lisp or SLIME preventing you from doing that, so I don't understand the issue here. The way you work is not incompatible with what I say (what I suggest doesn't exist fully, mind you); I work in the same way with Lisp as you suggest. I work like that in other languages too; I literally need 0 modern tooling for that. With 'modern' virtually worthless stacktraces, my tests are much faster at finding issues than a debugger. Anyway; I think we are not far removed, just for some reason you keep hanging in that image based thing while I didn't suggest that, at least not in any traditional sense. And you don't have to use it; it seems it needs to be clearer that there is choice and traditional image based execution is considered bad practice; that's fine and a good plan.
vindarel 2y ago
see: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Atom/Pulsar (good to very good support), VSCode, Sublime, Jetbrains, Jupyter notebooks, vim, Geany (experimental), Lem (built in CL)…

First step would be to support SLIME in editors other than Emacs.

kagevf 2y ago

vim has 2 implementations of slime. Lem is a new editor written in Common Lisp that has slime "built-in".

tocariimaa 2y ago
> vim has 2 implementations of slime. Which are both buggy and one of them is abandoned. > Lem is a new editor written in Common Lisp that has slime "built-in". "Lem" is not (neo)vim, has Emacs RSI bindings and even if by some chance it included some "vi mode", it would simply be an emulation, not an actual vi editor. Same issue with Emacs using "evil mode".
- kagevf 2y ago
  > even if by some chance it included some "vi mode", it would simply be an emulation, not an actual vi editor Lem supports vim key bindings, according to its README. btw, I don't have any issues with emacs keybindings, but I chuckled at the "Emacs RSI bindings" :) In fact, I think vim keybindings are superior for editing - you can't beat hitting "." to repeat an action - but after using emacs for ~5 years I find myself in it a lot more than I expected when I started using it. The whole thing with key bindings is that for whichever one(s) you use your muscle memory catches up.

nickelpro 2y ago

I despise SLIME. It made perfect sense in 2003 and was way ahead of the game compared to every other language for decades, but today we have the language server protocol and every effort should be made to support that instead. Anecdotally, the AliveLSP works fine although it suffers from the same "Why would you want a standalone program? Load it into the REPL" problems I derided in response to the parent.

anonzzzies 2y ago
I guess SLIME just works well for most as I would say it is still ahead every time I see python devs using their 'great tools' including a lsp in pain. I like a lsp where, during development, my core runs and I can see live feedback of it running when I make changes. Kind of like, you know, an image. That does not say you need to depend on that image outside dev (like an lsp, reset it when you reload a project, quit the editor etc), but during dev it's just superior imho.
- nickelpro 2y ago
  Ya, this is the core of the disagreement that I would run into with the old school lispers. I see it, I do, my third eye is open. I get the entire flow that the interactive development environment brings to the table and how it is infinitely superior than what existed in every other language for decades. But I don't like it more than the modern tooling. That's pure personal preference. I don't like this weird stateful thing hanging out in the background of my dev environment. I don't find value in sending random expressions into the weird stateful blob. If I wanted to drop into a debugger, I'll ask, don't hijack my stacktraces. I write tight test loops, modify my code, run the tests from scratch in the same one-key press the lispers use to evaluate their s-expressions. I don't need to go back and verify my build or application works from scratch, it never breaks, I'm constantly rebuilding. I would run into situations not infrequently where some post-doc wasn't quite sure how they achieved the state they did in the image, had a bug, but no tests to reproduce the bug or anything else. Maddening. An anti-pattern I never saw accomplished to the same degree with the Python boys (not to say Jupyter Notebooks aren't their own stateful fucking mad house of bad software engineering).
  - anonzzzies 2y ago
    I still see those as different things; if there is no 'state' besides running your code as in files as you edit it and it kills the image when you stop, how did you get to : > how they achieved the state they did in the image Because in my view, there is no image beyond your debug session. But yeah, it would be nice to sit together at a meetup and you showing me what's so great about this modern tooling, because the modern tooling is terrible in my opinion. Sure, a debugger is ok-ish, when it works (which is sketchy at best if I see my friends trying to debug nextjs/react in vscode and breakpoints not hitting or in the wrong place etc etc or simply completely not working etc, but let's say it works perfectly); you still cannot just quickly test different path etc. I have been programming for well over 40 years and I did lisp/prolog in uni, then I went to the usual, Java, C#, JS/TS, Python, C/C++, Pascal/Delphi etc before trying lisp (&prolog) again and finding the modern tooling fairly lacking and annoying. What you do, as you describe it, has simply nothing to do with modern test tools; you could do TDD with tight test loops in 1993 and it was a good way to do things. There is nothing in Coomon Lisp or SLIME preventing you from doing that, so I don't understand the issue here. The way you work is not incompatible with what I say (what I suggest doesn't exist fully, mind you); I work in the same way with Lisp as you suggest. I work like that in other languages too; I literally need 0 modern tooling for that. With 'modern' virtually worthless stacktraces, my tests are much faster at finding issues than a debugger. Anyway; I think we are not far removed, just for some reason you keep hanging in that image based thing while I didn't suggest that, at least not in any traditional sense. And you don't have to use it; it seems it needs to be clearer that there is choice and traditional image based execution is considered bad practice; that's fine and a good plan.

vindarel 2y ago

see: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Atom/Pulsar (good to very good support), VSCode, Sublime, Jetbrains, Jupyter notebooks, vim, Geany (experimental), Lem (built in CL)…