6 ms·

Nice to see more LISP posts.

by xiaoyu2006 2y ago

anonzzzies 2y ago
We need to at least try to get rid of the bad (old) perception; Common Lisp (with SBCL and some others) is a very viable environment for most things people want to do besides hiring bags of people (for now anyway).
- nickelpro 2y ago
  Image-based development is a dead end. Whatever one's feelings are about interactive development, any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else is totally insane as a production product. And this is unfortunately how most Lisp tooling still works. Quicklisp and friends assume you're fulfilling external dependencies by evaluating things in the REPL. This is without mentioning that the entire ecosystem of external dependencies ships monthly as one monolithic group. Versions? Lockfiles? Nah dog, give me "October 2023". The only person trying to fix this if Fukamachi with Roswell and qlot, and those are very recent projects (in the scale of Common Lisp), that have gotten irrational amounts of resistance from lispers. C now has project-local dependency management thanks to vcpkg/conan/Spack/etc, but lispers still insist that ~/common-lisp is good enough for every single project they will ever work on.
  - kagevf 2y ago
    > any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else Implemenations like SBCL can produce executables. Source code is stored in files and can be versioned. > The only person trying to fix this [is] Fukamachi There are other ways to get dependencies, such as ultra lisp https://ultralisp.org/ https://ultralisp.org/ and OCICL https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl.
    - nickelpro 2y ago
      Yes, of course, that's why I brought up Fukamachi's work to point out that things can be better. It is possible to forego the mechanisms of interactive-development that intersect with image-based development, but that requires lispers to change how they've done things for generations. Neither the ecosystem or culture is aligned to it. Ultralisp + Roswell + qlot produces something resembling a modern development workflow, but it is swimming upstream. ASDF is totally inadequate as a build system, it makes CMake appear terse and elegant by comparison (why on God's green earth is the present working directory not searched for the package I'm trying to build, like every other build system to ever exist?). Documentation and tutorials assume you're pulling things down with quicklisp and evaluating in the REPL. /r/Common_Lisp posters wonder why you would even want to use dependencies at all when you could just use [incomprehensible, brittle, unhygienic macro]. It has become possible, in the last two years or so, to produce sane common lisp workflows that operate somewhat like other modern environments. I very, very rarely encounter that usage in the wild. I would like nothing more than for the Common Lisp infrastructure to produce environments and workflows as obvious, intuitive, and correct as what every undergrad using Python in VSCode has today. I do not think the broader language ecosystem is there yet.
      - kagevf 2y ago
        > why on God's green earth is the present working directory not searched for the package I'm trying to build, like every other build system to ever exist? What if you want to share packages (aka CL systems) between different CL systems / applications?
        nickelpro 2y ago
        Do it the same way every language environment not named Common Lisp does?
  - anonzzzies 2y ago
    There might be people using cl like that, I don't know these people. We just use files and versioning and execute saves and versioned snippets in slime which works fast and well but is not image based development at all.
  - stassats 2y ago
    >any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else is totally insane as a production product. Nobody does that.
    - anonzzzies 2y ago
      Yes, I am confused where people get that idea. 30 years ago in irc maybe? (not dissing on irc: i was one of these people 30 years ago)
      - nickelpro 2y ago
        I could very well be unlucky, and my experience is mostly with academics (not much industry usage of CL anymore). But if I had a nickel for everytime I got emailed a core file I would not have had to be working in academia.
  - tmtvl 2y ago
    I use OCICL, it's pretty great. That is, as long as you ignore it's basically one guy and his GitHub profile. It's unfortunate clpm died, that could've also been interesting.
  - tho3i2424234 2y ago
    It largely is fine though. Dependency management is Lisp-like languages without a separate binary-compilation stage typically only breaks when you have external dependencies.Pip would be fine if everything was in Python; it's not because numpy/protobuf/jax/pytorch/... breaks everytime you look look at it. CL libs are nowhere near that level of cross-dependency and all of them get built in a local cache when you first start anyway, so you can pretty much "lock" the versions by git sub-module-ing them. It's very nix-like way of working (IME things only ever break on the CL-<outside world> barrier).
- tocariimaa 2y ago
  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.

Nice to see more LISP posts.

We need to at least try to get rid of the bad (old) perception; Common Lisp (with SBCL and some others) is a very viable environment for most things people want to do besides hiring bags of people (for now anyway).

nickelpro 2y ago
Image-based development is a dead end. Whatever one's feelings are about interactive development, any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else is totally insane as a production product. And this is unfortunately how most Lisp tooling still works. Quicklisp and friends assume you're fulfilling external dependencies by evaluating things in the REPL. This is without mentioning that the entire ecosystem of external dependencies ships monthly as one monolithic group. Versions? Lockfiles? Nah dog, give me "October 2023". The only person trying to fix this if Fukamachi with Roswell and qlot, and those are very recent projects (in the scale of Common Lisp), that have gotten irrational amounts of resistance from lispers. C now has project-local dependency management thanks to vcpkg/conan/Spack/etc, but lispers still insist that ~/common-lisp is good enough for every single project they will ever work on.
- kagevf 2y ago
  > any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else Implemenations like SBCL can produce executables. Source code is stored in files and can be versioned. > The only person trying to fix this [is] Fukamachi There are other ways to get dependencies, such as ultra lisp https://ultralisp.org/ https://ultralisp.org/ and OCICL https://github.com/ocicl/ocicl https://github.com/ocicl/ocicl.
  - nickelpro 2y ago
    Yes, of course, that's why I brought up Fukamachi's work to point out that things can be better. It is possible to forego the mechanisms of interactive-development that intersect with image-based development, but that requires lispers to change how they've done things for generations. Neither the ecosystem or culture is aligned to it. Ultralisp + Roswell + qlot produces something resembling a modern development workflow, but it is swimming upstream. ASDF is totally inadequate as a build system, it makes CMake appear terse and elegant by comparison (why on God's green earth is the present working directory not searched for the package I'm trying to build, like every other build system to ever exist?). Documentation and tutorials assume you're pulling things down with quicklisp and evaluating in the REPL. /r/Common_Lisp posters wonder why you would even want to use dependencies at all when you could just use [incomprehensible, brittle, unhygienic macro]. It has become possible, in the last two years or so, to produce sane common lisp workflows that operate somewhat like other modern environments. I very, very rarely encounter that usage in the wild. I would like nothing more than for the Common Lisp infrastructure to produce environments and workflows as obvious, intuitive, and correct as what every undergrad using Python in VSCode has today. I do not think the broader language ecosystem is there yet.
    - kagevf 2y ago
      > why on God's green earth is the present working directory not searched for the package I'm trying to build, like every other build system to ever exist? What if you want to share packages (aka CL systems) between different CL systems / applications?
      - nickelpro 2y ago
        Do it the same way every language environment not named Common Lisp does?
- anonzzzies 2y ago
  There might be people using cl like that, I don't know these people. We just use files and versioning and execute saves and versioned snippets in slime which works fast and well but is not image based development at all.
- stassats 2y ago
  >any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else is totally insane as a production product. Nobody does that.
  - anonzzzies 2y ago
    Yes, I am confused where people get that idea. 30 years ago in irc maybe? (not dissing on irc: i was one of these people 30 years ago)
    - nickelpro 2y ago
      I could very well be unlucky, and my experience is mostly with academics (not much industry usage of CL anymore). But if I had a nickel for everytime I got emailed a core file I would not have had to be working in academia.
- tmtvl 2y ago
  I use OCICL, it's pretty great. That is, as long as you ignore it's basically one guy and his GitHub profile. It's unfortunate clpm died, that could've also been interesting.
- tho3i2424234 2y ago
  It largely is fine though. Dependency management is Lisp-like languages without a separate binary-compilation stage typically only breaks when you have external dependencies.Pip would be fine if everything was in Python; it's not because numpy/protobuf/jax/pytorch/... breaks everytime you look look at it. CL libs are nowhere near that level of cross-dependency and all of them get built in a local cache when you first start anyway, so you can pretty much "lock" the versions by git sub-module-ing them. It's very nix-like way of working (IME things only ever break on the CL-<outside world> barrier).
tocariimaa 2y ago
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.