When learning a new language I find it really helpful when I'm strictly told what *not* to do, so if you need to get any lisp related rants off your chest I'd love to hear them.
Which lisp? Are we talking about the Common Lisp or the Uncommon Lisp (Scheme)?
* Don't refer to Common Lisp as "lisp" or "Clisp" (Clisp is an implementation of Common Lisp).
* One tip I have for Common Lisp is that do not use the Quicklisp package manager because Guix package manager provides better security, as far as I know.
* Another tip is that you should use GNU Emacs, with either Slime or Sly. For Scheme, you should use Geiser.
* I recommend avoiding macros at first.
* Also, don't use the shorthand "forms" of CAR and CDR when you are writing the first versions of your program. By shorthand form, I mean that you can abbreviate CAR with A and CDR with D. To understand what this means, open a REPL and type: (caddr '(1 2 3)) the result should be same as if you typed (car (cdr (cdr'(1 2 3))))
>>2
Unfortunately, Guix is for Linux only. It can't be used on BSD, OS X, or Windows.
Which lisp?
Just in general like what you wrote here. I'm probably going to dive into scheme first, but my main "worry" here is that I carry some bad habits from the procedural programming world which I'm more familiar with.
>>4
You might be interested in a book called Little Schemer. It has set of laws and commandments that are designed to aid new Scheme programmers. I found list of them online: https://github.com/grassdog/The-Little-Schemer/blob/master/ten-commandments-and-five-rules.md
Also, it is important to keep in mind that Lisp is not limited to functional programming paradigm. However, Schemers often prefer functional paradigm.
>>3
It's not Linux only, since it also works on GNU Hurd.
If you're working with CL, the lisp-critic package may help (it's in quicklisp).
If you're working in another, more minimal, language it's worth seeing how far you can get by just staying withing the boundaries of the language report (e.g. R6RS, R7RS-small, ISLisp). I'd recommend implementing any features that depend on stuff outside the standard language in separate modules, which in addition to preparing the ground for portability just leads to a nicer design.
Don't try to write Lisp in languages that are not Lisp. Don't try to avoid writing Lisp in languages that are not Lisp.
And try to write a spec for, fix bugs in or optimize it.
And don't try
fix
f