plump VS mu

Heh, that thread brings to mind a bunch of things... One advantage of CL that helps with a 'borrowing' aspect that give people the jeebies is that the unit of compilation is much smaller than the file, so you can also borrow much less. Another is that methods are decoupled from classes so there's a lot of room for extensibility. (The LLGPL interestingly provides an incentive for the open-closed principle, i.e. you extend objects you're fine, but if you modify the library's then you are subject to the LGPL.) If you haven't read Gabriel's Patterns of Software book (free pdf on his site), I think you'd enjoy it.

Your edits won't get blown away, at least by default, since quicklisp doesn't redownload a system that it knows about or check for 'corruption'. The way quicklisp does its own versioning also means if you update quicklisp's distributions lists and a newer version of the library has come out, it'll download that one into its own new folder and leave the old one alone. There's a cleanup function to clear out old things but I don't know of a case where that gets called hidden from you under the hood.

Maybe there's some magic and interesting stuff related to this for emacs but I'm a vim heretic ;) But in any case if you want to save stuff, you can just save it in a new or existing buffer... So options are basically as I described. To give a specific example, I have a script that fetches and parses some HTML to archive comments and I wanted to remove the HTML bits so I'd just have text, making it more markdown-y. There are lots of ways to do that and I'm pretty sure I chose one of the worst ones, but whatever. I was already using the Plump library, and after not achieving full success with its official extension mechanisms, one method I came across and stepped through was https://github.com/Shinmera/plump/blob/master/dom.lisp#L428 and I decided I could hijack it for my purposes. I started by editing and redefining it in place until I got what I wanted, but instead of saving my changes over the original, I simply copied it over to my script file, modifying slightly to account for namespaces e.g. it's "(defmethod plump-dom:text ((node plump:nesting-node))", thus redefining and overwriting the library implementation when my script is loaded and run.

Some possible problems with this approach in general include later trying to integrate that script with other code that needs the default behavior (though CL support for :before/:after/:around auxiliary methods can help here, e.g. if I can't just subclass I could insert a seam with an :around method branching between my custom implementation over the library's without having to overwrite the library's; and in the long-term the SICL implementation will show the way to first-class environments that can allow multiple versions of stuff to co-exist nicely). Or the library could update and change the protocol, breaking my hack when I update to it. Or in other situations there may be more complex changes, like if you modify a macro but want the new modifications to apply to code using the old def, you need to redefine that old code, or if you redefine a class and want/need to specially migrate pre-existing instances you need to write an update-instance-for-redefined-class specializer, or if the changes just span across a lot of areas it may be infeasible to cherry-pick them into a 'patch' file/section of your script, so you're faced with choices on how much you want to fork the files of the lib and copy them into your own project to load. But anyway, all those possible problems are on me.

The asdf noise isn't that big of a deal and I think is only a little related here technically since it's a rather special library situation. It's more 'interesting' socially and as a show of possible conflict from having a core piece of infrastructure provided by the implementation, but not owned/maintained by the implementation. An analogous situation would arise if gcc, clang, and visual studio all agreed to use and ship versions of musl for their libc with any other libcs being obsolete and long forgotten. A less analogous situation is the existing one that Linux distributions do -- sometimes they just distribute, sometimes they distribute-and-modify, whether they are the first place to go to report issues or whether they punt it off to upstream depends case-by-case.

Depending on how minimal a distribution you want, a few years ago I had a way to take a single ELF binary created by my computing stack built up from machine code (https://github.com/akkartik/mu) and package it up with just a linux kernel and syslinux (whatever _that_ is) to create a bootable disk image I could then ship to a cloud server (https://akkartik.name/post/iso-on-linode, though I don't use Linode anymore these days) and run on a VPS to create a truly minimal webserver. If this seems at all relevant I'd be happy to answer questions or help out.

This was the thinking behind my https://github.com/akkartik/mu

Yes thank you, I was indeed alluding to https://github.com/akkartik/mu. Perhaps a more precise term would be "software stack".

I built a computer with its own languages, and I consider it to be _less_ cognitive load when everything is in 1/2/3 languages. I don't have to worry that the next program I want to read the sources will require "Go, Rust, C++, JS/TS, Python, Java, etc."

There are other metrics to consider besides your notions of cognitive load and productivity. Inferno predates most of the languages on your list. My computer (https://github.com/akkartik/mu) uses custom languages because I was able to design them to minimize total LoC, and to ensure the dependency graph has no cycles (unlike all of the conventional software stack, at least until https://www.gnu.org/software/mes connects up all the dots).

"Separation of concerns is a hard-won insight."

Absolutely. I'm arguing for separating just concerns, without entangling them with considerations of people.

It's certainly reasonable to consider my projects toy. I consider them research:

* https://github.com/akkartik/mu

* https://github.com/akkartik/teliva

"The idea that projects should take source copies instead of library dependencies is just kind of nuts..."

The idea that projects should take copies seems about symmetric to me with taking pointers. Call by value vs call by reference. We just haven't had 50 years of tooling to support copies. Where would we be by now if we had devoted equal resources to both branches?

"...at least for large libraries."

How are these large libraries going for ya? Log4j wasn't exactly a shining example of the human race at its best. We're trying to run before we can walk.

I still believe :) I'm looking not for an economic argument but for a strategic one. I think[1] a self-hosted setup with minimal dependencies can be more resilient than a conventional one, whether with a vendor or self-hosted.

https://sandstorm.io got a lot right. I wish they'd paid more attention to upgrade burdens.

[1] https://github.com/akkartik/mu

I'm very interested in the network stack, having explored it for a while for https://github.com/akkartik/mu before giving up. What sort of network card do you support?