I thought I would forward this message I sent to Lisp-HUG (the LispWorks users mailing-list), which is about ASDF.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org In a mature society, “civil servant” is semantically equal to “civil *master*”. — Robert Heinlein, “Time Enough For Love” ---------- Forwarded message --------- From: Faré <[email protected]> Date: Sun, Nov 30, 2025 at 11:38 PM Subject: Re: Naive DEFSYSTEM replacement To: Adam Weaver <[email protected]> Cc: [email protected] <[email protected]> Sorry to only reply months later---I don't actively follow the lisp-hug mailing list. On Sun, Jul 27, 2025 at 7:24 PM Adam Weaver (as adam at cleversure dot com dot au) <[email protected]> wrote: > Obviously *no-one* really knows (nowadays) why ASDF is > as complicated in its implementation as it is. > 1. Having written, rewritten or carefully reviewed each and every line of code in ASDF 3.3.4, I do know what each and every line of it is about. Robert Goldman has been maintaining it since I left the CL community (thank you so much, Robert), but his commits are clean and easy enough to follow, and I am confident I can grok the diffs if needed---and happily or unhappily, it's not that much diffs. While I'm not active in CL anymore, my knowledge of ASDF is still available to Robert and any developer or user of ASDF when needed. 2. ASDF is actually not complicated at all. COMPARED TO WHAT??? The equivalent in the C universe would be a mix of libc (portability layer), make (building files), ld.so (recursive dynamic loader), autoconf (features detection), pkg-config (library path detection), ld (static linker---ASDF can create standalone binaries). If you count the lines of code in all these pieces of blub, even if you strip the parts that ASDF doesn't cover (because you don't need them to build, or at least not when you have CL), you'll get something more than 10x larger than ASDF. 3. ASDF can build software *and incrementally update it*, in-image, portably, across tens of implementations including some you've never heard of on operating systems you don't suspect exist. And then, ASDF is itself extensible, from within ASDF; and unlike any other build software in any other language bar none, it handles extensions to the build system from within the build system, through arbitrary many layers of extensions-loading-extensions, in the same session. 4. Every line is necessary, though I admit there are a couple of UIOP functions I added only so UIOP could claim 100% functionality coverage as a replacement for CL-FAD. Even the NEST macro is necessary, seeing how it interacts with #+ in launch-program and such, though ASDF doesn't reach the 19-level deep that my LIL code reaches (and so NEST belies the joke about the end of an AI written in Lisp). I challenge you or anyone to show me a function you think has unclear or unnecessary purpose---the internals are well commented and the exported functions are well documented. 5. More than half of ASDF is actually the portability layer UIOP. I broke up the source code into many files for ASDF 3, and since then it is well organized in a logical way that is relatively easy to follow if you read the files in the dependency order declared in the .asd files. While the documentation could always be improved, I have no doubt that any serious would-be maintainer could read the documentation (for the concepts) then the source code (for their implementation) and come to understand ASDF in a matter of days, though it might still take weeks or months to really grok how the system just all fits together. The subtlest bit I believe would be CRDT underlying action-status (in plan.lisp); yet considering all the functionality it affords I still wouldn't call it "complicated". PS: I am currently looking for permanent or temporary work, and would gladly take a contract that involves CL. Regards, —♯ƒ • François-René Rideau • Chief Scientist, MuKn.com/fare “A slave is one who waits for someone else to free him.” — Ezra Pound
