[HN Gopher] Depending in Common Lisp - Using the CLOS dependent ...
___________________________________________________________________
Depending in Common Lisp - Using the CLOS dependent maintenance
protocol (2022)
Author : florgy
Score : 81 points
Date : 2025-02-25 19:42 UTC (4 days ago)
(HTM) web link (stevelosh.com)
(TXT) w3m dump (stevelosh.com)
| xiaoyu2006 wrote:
| Nice to see more LISP posts.
| anonzzzies wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| nickelpro wrote:
| 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 wrote:
| > 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 wrote:
| Do it the same way every language environment not named
| Common Lisp does?
| anonzzzies wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tocariimaa wrote:
| First step would be to support SLIME in editors other than
| Emacs.
| kagevf wrote:
| vim has 2 implementations of slime.
|
| Lem is a new editor written in Common Lisp that has slime
| "built-in".
| tocariimaa wrote:
| > 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".
| nickelpro wrote:
| 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.
| dack wrote:
| this is cool, but holy crap that's a lot of work for a seemingly-
| simple type of feature!
| BoingBoomTschak wrote:
| Even if some stuff could be simpler, I'll hazard a guess and
| say it's the cost of flexibility and "correctness".
| kagevf wrote:
| All in the service of interactivity, a key feature of CL.
___________________________________________________________________
(page generated 2025-03-01 23:00 UTC)