[nyir]

Great points on the list too, even though I still think they're more the acceptable trade-offs kind of bad. I.e., yes, of course `caddddr` will be unreadable, probably, so just don't. `declaim` has a sharp edge for a reason, but you can also make things better by increasing the debug and safety level, that's a great idea I really haven't seen repeated elsewhere.

The JSON library makes sense, there are several ones and they're all making different decisions wrt. representing the JSON types. I wonder if anyone made a comparison of them with https://news.ycombinator.com/item?id=20724672, that would be useful.

Lastly, I'd always add "be wary of pathnames", even though I was (am) a big fan of the concept in general, it's just sometimes a bit fiddly with regards to physical filenames that can appear on various systems (that's e.g. why SBCL's `native-namestring` can be necessary, http://www.sbcl.org/manual/#Pathnames).

[time_to_smile]

> yes, of course `caddddr` will be unreadable, probably, so just don't

I've found in general, while cute that they exist, the ca*d*r family of functions are certainly a code-smell in any lisp/scheme. They're typically a sign you really want a rather different data structure than a list, and if not they can almost always be replaced with `drop`/`take`.

[hajile]

https://sabracrolleton.github.io/json-review.html

The differences are pretty big. Some use associated lists, some use hash tables, some convert to CLOS, etc