Hacker News Reader

> 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/ and OCICL https://github.com/ocicl/ocicl.

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.

> 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?

Do it the same way every language environment not named Common Lisp does?

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

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)

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.

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

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.

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.