I find lisp really hard to learn.

I don't mean the syntax, or the concept of macros (though I'm sure my understanding of macros is incomplete) but what I find is lacking in the documentation is how one actually might use lisp.

I read stories about "connecting to" a "running lisp" on a space probe and debugging in real time. Does that mean some lisp implementations listen on a tcp port? How does one actually connect to or disconnect from a repl? Is it just that when NASA launched their probe, someone went in on ssh and moved the process to the background with C-z?

How does one deploy a lisp application? Can I compile my code into an executable with, say, sbcl which is what everyone seems to use? Or am I forced to rsync all my source code to my server and get e.g. systemd to manually invoke an entry point?

SBCL has a manual, your main questions are answered in it: http://www.sbcl.org/manual/

Under the dev-tools/editor section you'll see slime mentioned. It too has a manual: https://www.common-lisp.net/project/slime/doc/html/

It's common to use slime with emacs, but vim and atom work too. Slime includes a lisp program called swank which sets up a simple server that clients like emacs can open a socket to. In Common Lisp, "compile", "eval", "load", "break", etc. are built-in functions. Lisp programs are 'alive' and can be constructed or debugged and updated by compiling and executing bit by bit without having to suspend or restart the process, using the socket to communicate how to grow. Some examples are in this several part series you can take 10 mins to browse through: https://malisper.me/debugging-lisp-part-1-recompilation/ Going beyond that into say developing a full application with version pinning of dependencies and tests is documented in books/in pieces on the web (CL cookbook has a lot).

But manuals tell a lot too. Under SBCL's Saving a Core Image, you can see a standalone executable can be made with save-lisp-and-die. But you can also load things with --script if you want a python or node like experience.

I've read the SBCL manual before, several times. It's not suitable for learning Lisp; it's written for people who already know Lisp but need an implementation-specific question answered.

Let me illustrate:

Suppose I want to compile my lisp code into an executable for easy deployment. My first step is opening the SBCL manual and reading the entire section on the compiler. There's nothing in there about how to actually invoke the compiler. Maybe there's a command line option. Read section 3 and find the "saving a core image" section. It has lots of verbiage about saving state to disk so that you can restart the program in the same state.

But I don't want to restart in whatever garbled development state I'm currently in. I want the program to start in the initial state and progress normally, the way a program in just about any other language would naturally execute. I want execution to begin at the entry point (does Lisp even have "entry points"? There's another 5 hours of wasted time trying to figure that one out) and progress naturally like it does in literally any other language I can think of. By saving the current state how do I know I'm not introducing bugs due to some variable holding inadvertent state when I save-and-die?

Okay so now I'm down the rabbit hole of stackoverflow and personal websites from random PhD computer science students at Carnegie Mellon from 2001 and about now is when I usually get frustrated, say "fuck it", and move on to a language like C# that actually has good documentation with copious examples (not to mention a library for just about everything), has an execution model that's actually easy to understand, and move on with my life.

I say this as an aerospace engineer: I'm a smart guy but Lisp must be beyond my reach as a mere mortal without a computer science degree. I went through most of the Gigamonkeys book and while I can write a mean LOOP macro I can't actually do anything useful with lisp. The documentation is too confusing and too fragmented.

I want to like Lisp but it fights me every step of the way.

I guess I don't know what to say other than if you really want to learn Lisp, you have to meet it on its own terms. It's old, its heritage is older and always offered a different approach to the batch style of Fortran, it's not going to change for you.

I hate this kind of wording because it makes it seem that Lisp is mysterious, or super difficult, or requires a ton of unlearning, or has no good (and free) learning material (you knock it but I enjoy Steele's 30 year old cltl2 mirrored on a CMU page), or is only for impractical purposes and CS-guilded programmers. I don't believe any of that, there are plenty of examples to the contrary. In contrast your own difficulties are puzzling. I hesitate to suggest reading, watching, or doing anything else, though things come to mind, simply to avoid wasting your time or money further if you took me up on any of it, as it might all be useless.

>It's old, its heritage is older and always offered a different approach to the batch style of Fortran, it's not going to change for you.

I'm not asking for Lisp to change. I'm explaining why Lisp is hard to learn.

>I hate this kind of wording because it makes it seem that Lisp is mysterious [...] or requires a ton of unlearning

In my experience these things are 110% true. Even ASDF uses strange terminology completely divorced from modern usage. What are systems and modules, and how do they map to what every other language calls a package or a library? I have no idea. The "Getting Started with ASDF" page that was the top hit on Google works through an example where they define a Cow System that has legs, tail, head, etc. That's the usual example when talking about class inheritance... So are systems classes? What about CLOS?

How the fuck do I get packaging in lisp?

Again, here is where I usually give up.

>In contrast your own difficulties are puzzling.

Okay, well they're still the difficulties I'm hitting.

I see lots of puzzlement on HN and elsewhere as to why Lisp isn't more popular than it is, and I honestly believe this is partly why. I have a busy job and soon to be a second child; I could spend my time trawling through powerpoint slides from MIT courses that took place in 2008 trying to find the answers, or I could brave the extremely caustic world of stackoverflow (no thanks, I deal with enough condescension already), or I could just give up and pick a different language and get up to speed faster and with less frustration.

>I guess I don't know what to say other than if you really want to learn Lisp

I guess I did want to learn Lisp, until I actually started trying to use it. The language itself seems awesome but the ecosystem around it, including the onboarding experience for non-graybeards, is pretty bad.

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 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 "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 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/), this best practices guide linked from ASDF's home page (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), a short ebook I occasionally shill (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...). 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/

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