4 ms·

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 RE

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).

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).