> I'm explaining why Lisp is hard to learn. It is not hard to learn in general, there are too many counterexamples of people of all sorts and skills learning i

> I'm explaining why Lisp is hard to learn. It is not hard to learn in general, there are too many counterexamples of people of all sorts and skills learning it without these issues you are having, learning it as their first, learning it later in their careers... (CL is big, I'll give you that, but each piece can be chewed one at a time and does not seem to be individually that difficult.) So I can hypothesize why it's hard to learn for you. My first guess is still that you aren't meeting Lisp in its own terms and are trying to make Lisp fit your mental model of some other language and its ecosystem. This isn't going to work, and the failure mode (if I'm right) has nothing to do with Lisp but with biases in general heuristics of learning. You don't need to "unlearn" the way you're used to doing things, but you do need to separate yourself from it for a bit until you actually grasp the Lisp (and its ecosystem's) way(s) and can then see the connections, tenuous and non-existent as some may be. I'll risk raising some of those connections below, but really, things need to be understood on their own terms first or you wind up with misconceptions. (I've seen it multiple times with Java/Python programmers getting confused at the other's "import" statement.) > strange terminology It's not Lisp's fault that it's old. Being old means it will have terminology that may be alien to what we have today with nothing today being a perfect fit, or alternatively sometimes it expresses mostly what we say today in a different way. (And when you talk about concepts, not just pure language features, you run into incommensurability. See https://dreamsongs.com/Files/Incommensurability.pdf https://dreamsongs.com/Files/Incommensurability.pdf for an example with Mixins.) CLOS for example has these things called "slots" which are more or less "fields" or "class/instance variables" in later OOP languages. But it's best to think of them as CLOS slots, so that you don't bring along any (mis)conceptions from other languages. It's sometimes amusing how different other OOP systems are given CLOS was the first to be part of an ANSI standard. > that took place in 2008 I rather like that I can often find things decades old about Lisp and they are still relevant. Systems are at least as early as the Lisp Machine (1979). Perhaps it's worth going to the original description there? I also sort of like this history diving, even if modern sources obsolete the history in every way that matters. But here is the Lisp Machine manual on the topic: https://hanshuebner.github.io/lmman/maksys.xml https://hanshuebner.github.io/lmman/maksys.xml "The way it works is that you define a set of files to be a system, using the defsystem special form, described below." Is that unclear? Systems are first and foremost sets of files. Systems also let you define relations between files, primarily which files depend on which other files, as further sentences reveal. If you're talking about this page as the first result: https://common-lisp.net/~mmommer/asdf-howto.shtml https://common-lisp.net/~mmommer/asdf-howto.shtml I agree it's an awful guide. I've never seen it before, it's a shame it's the #1 result. You'd be best served by ignoring it. Systems have nothing to do with CLOS, I assume that guide started trying to use animal parts as a way to elucidate dependencies. (A tail doesn't actually depend on legs though?) I don't recall how I learned systems, probably because a mix of ASDF's manual (https://common-lisp.net/project/asdf/ https://common-lisp.net/project/asdf/), this best practices guide linked from ASDF's home page (https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/best_practices.md https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/bes...), just looking at example asd files of popular libraries and applications (https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl), a short ebook I occasionally shill (https://www.darkchestnut.com/book-common-lisp-application-deployment/ https://www.darkchestnut.com/book-common-lisp-application-de...), and just actually writing enough lisp and making my own library, were in part or all together enough. When you're actually writing software, you can just incrementally compile and load your files (or just eval chunks you've selected with the editor), or if you made a bunch of changes across the whole project then you can just reload your system (if you've defined it) and have everything recompiled and reloaded for you. It's worth noting that systems are not part of the ANSI Lisp standard, though. Just as Maven is not part of Java. If you jump straight to Maven without first understanding how to create a Java program with multiple files using javac and jars, you might have a hard time later. Lord knows plenty of people get by relatively fine skipping around though (and might not even touch Maven directly, just do everything from an IDE); you can do this with Lisp too, but you seem to want to understand things more fundamentally. Probably what you need to understand most is the core function "load" (http://www.lispworks.com/documentation/HyperSpec/Body/f_load.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_load...). After that you probably want to know about packages (which are akin to namespaces -- bags of symbols, if you already know what 'symbol' means in the CL context). You may wish to know about the "modules" mini-feature enough to know it's deprecated and doesn't really provide anything like what you think a module system should, so no one uses it, and that this mini-feature is independent from something else you might find rarely mentioned in ASDF that is unhelpfully called a 'module'. > packaging in lisp? Lisp itself doesn't have a notion of "packaging" in the meaning I'm inferring from you, so your question is wrong on its outset. It just has things like compile-file and load. If you like, you can loosely refer to a directory of files you load one by one as a "package" or a "library". You can define a system for those files with ASDF, and treat "loading the system" as something like "loading the library". When you want to get other "libraries" (directories of files -- just like python eggs or java jars, but lisp libs aren't compressed into zips) from the internet, or publish your own, the community standard is https://www.quicklisp.org/beta/ https://www.quicklisp.org/beta/ Sorry if this is just more unhelpful text, I can feel your frustration even if I don't fully understand it. I do agree that being alien is a detriment to Lisp's popularity, but that's not going to change. You might find some leverage by working at CL from the less alien Clojure as a starting point. I always thought this two part talk on Clojure for Java Programmers was really good, but the last person I sent it to dozed off watching it, so your results may vary: https://www.youtube.com/watch?v=P76Vbsk_3J0 https://www.youtube.com/watch?v=P76Vbsk_3J0