Ah yes this is exactly what I needed. I was recently trying to start a CL project but I had trouble wading through all the outdated material, especially with regards to including external packages. Thanks for putting this together!
A package in Common Lisp is a set of interned symbols. In Common Lisp, systems are more in keeping with an ordinary understanding of packages...but combined with the idea of a build system just for fun.
ASDF is a way for managing systems (but it is worth keeping in mind that Common Lisp does not have any 'official' understanding of systems). ASDF is pretty much a de facto standard by consensus.
Quicklisp is a 'package manager' in the sense that it will go out and fetch a dependency from a repository. But what it fetches is a system: it is usually not a package in Common Lisp's technical sense.
From the Quicklisp FAQ:
How is Quicklisp related to ASDF?
Quicklisp has an archive of project files and metadata about project relationships. It can download a project and its dependencies. ASDF is used to actually compile and load the project and its dependencies.
ASDF is a little like make and Quicklisp is a little like a Linux package manager.
On the other hand, Common Lisp is very stable around ASDF and SLIME and QuickLisp. ASDF was started in 2002. Quicklisp in 2005. SLIME in 2003.
I would be interested in any PRs you have to clarify the matter adequately for people just starting out.
0. It's a hard problem. I have a deep respect for your trying to tackle it.
1. The hard part is that it all matters on day one and everyone will get a lot of stuff wrong for a long while and some stuff wrong always when attempting non-trivial projects. This is the rule whether it's Python or Common Lisp or Racket.
2. I'm a fan of polyglotting languages in general and Lisp's in particular. For a person really just starting out, I'd point them at the Racket ecosystem because it is designed to be newbie friendly with student languages and Common Lisp is designed for production programming on hard problems.
2. For people with some programming experience and simple curiosity, I'd just advise them to install SBCL and play around in the REPL. With an exercise of adding a script to wrap it in readline. And some exercises using the text editor of their choice to load and read and write files and such.
3. I don't think that there's a way to add training wheels to SLIME and Quicklisp and ASDF as the development environment. It just won't ever be DrRacket. At best it produces something like Aphyr's Clojure from the Ground Up...which uses Emacs; is more like a book; and definitely a labor of love. It also dives into the details at day one.
None of which means I might not submit a pull request. But I take what Norvig says seriously -- http://norvig.com/21-days.html
Again, kudos for taking it on.
But what is typically lacking is how you go from just a Lisp environment to a development environment that lets you operate at a professional level. Articulate-lisp is intended to deliver the thumbnail of how to get that put together, along with assorted references to further study.
At the time I created it, there was nothing really suitable for pro development out there. I guess roswell and portacle are things now.
Training wheels aren't really my bag of things. I'm notorious for preferring to read the O.G. paper on subjects rather than work through tutorials and simplified whatsits. But giving all the data at once doesn't provide the map of the territory that newbies crave.
There's no Royal Road to Lisp... or geometry. But a map to get you to where you're going does exist for geometry, and Lisp, I think deserves one too.
If that-all makes sense.
I think a resource for "leveling up" is probably better if it is opinionated. I mean, there are reasons a person might not want to use Emacs for Common Lisp development (aside from using a product with a built in IDE), but there's no reason to handle edge cases which have little to do with "leveling up" on Common Lisp...there may be a SLIME mode for Atom, but someone who chooses it is swimming upstream in terms of Common Lisp.
The situation is similar in regard to Lisp installations. There are good reasons not to use SBCL, but they probably don't have that much to do with "leveling up" (again outside the commercial IDE world) and trying to cater to those non-leveling up reasons is a distraction.
To put it another way, a person who is just starting out is not in a position to make decisions based on experience. A year later, they may have the experience to make informed decisions because they have learned what matters and what does not.
I hopeful for Roswell and Portacle, but not terribly optimistic in ways that are similar to when I hear about a new Linux distro. The hard work is not the exciting honeymoon period. It's grinding out maintenance over the years without getting paid. It's designing good features for other people without getting paid. Most projects cannot do it.
Part of the problem is that leveling up on Common Lisp is mostly a matter of will to RTFM. Sure a site can have a great article explaining Common Lisp packages, but to understand packages, readers will need to understand symbols and so the options are:
1. Expect the reader to already understand symbols.
2. Describe all of Common Lisp.
3. Accept that the reader will still have a lot of work to do after reading the article.
1 and 3 collapse into similar requirements for an author. 2 works if the author writing a book and really knows their stuff.
Not sure how any of that is applicable here.