Daniel Herring wrote:
Hi all,
This has bugged me for years, and recent traffic brings it back to the forefront. I apologize that this email is more a teaser than a complete solution, but that's what time allows for right now.
In my opinion, a lot of the complexity in ASDF is caused by its conflation of two separate goals: a "build system" and a "loader".
IMO a lot of the confusion about ASDF is caused by not understanding that systems like CL and Smalltalk don't actually have build systems or loaders. They have constraint systems that aim to preserve the integrity of a running image over modifications to code.
I believe Faré and I discussed this issue in our first ASDF paper at ILC. For an even more radical proposal, see McDermott's earlier ILC paper about his chunking mechanism, which allows programmers to specify integrity constraints even for individual data structures.
Thinking about ASDF this way, instead of trying to fit it into the world view of make, clarifies a lot of the sisues.
If CL is to grow from a dev-centric ecosystem to have a large base of "normal users", I think we need to start finding ways to enable better long-term stability. Pre-tested, "binary" releases are exactly what an end user wants. Applications need to "just work" and not break whenever a dependency changes its API.
Normal users don't want to build or load their software at all, nor do they want a CL environment. They want to click on an icon and have a program start and run.
ASDF does not have anything to say to normal users, any more than make, ant, ocaml, or gcc does.
This is not an application area to which ASDF will aspire during my tenure as maintainer.
The sole exception is that ASDF will continue to support *programmers* (not users) who want to use ASDF to describe how to build standalone executables for delivery.
ASDF is a programmer's tool. Users will have to find someone else to meet their needs.
My resources are stretched to the limit maintaining ASDF as the tool it is today.
Best, r