With regards to documentation you can see Documenting Guile code and my rant on documentation in the guile-user mailing list Some issues with guile You can also read my issues when trying to create my own doc system New blog post by Andy Wingo: on hoot, on boot - #2 by spacebarista
My conclusion is twofold:
- The situation isn’t as satisfactory as it could be.
- The strong point of Lisp is REPL-driven development, which is a fast-paced way develop programs, and writing tests and thorough documentation only slows you down.
If you want to get the best experience for Guile, I recommend that you focus on learning more about the REPL-driven development style. Some information on the manual of Guile: REPL Commands (Guile Reference Manual) and some notes on what REPL-driven development is: On repl-driven programming - by mikel evins
Debugging exists, you can navigate stack frames and so on with the commands listed in the Guile manual link above. A trial session might leave you confused because you’ll end up deep within Guile’s tail-called code (akin to stepping into glibc on gdb.) You will only get the hang of it once you start writing code and you’ll want to debug your own code. If you want to debug Guile lisp the same way you debug C down to reading assembly instructions, you should read Guile Implementation (Guile Reference Manual) although it is expert-level stuff, definitely harder than learning a bit of x86 and inspecting disasm on gdb.
There is no linting in lisp as far as I know. It’s not easy because everything being dynamic, you can update the code at any time. So static analysis cannot be “perfect”. Not that it shouldn’t be a thing at all though, but nobody has done the work for Guile lisp.