Bad NREPL: Things You Hate About NREPL

By acknowledging a complaint as valid I'm kind of addressing it. :-) Some things are real problems that I don't have the time to fix quickly. I can either make promises that I can't keep or be open about this. From time to time someone gets inspired to help.

> "It's not Clojure specific" is immediately followed by "so there are some protocol responses that people had to reverse-engineer that are tightly coupled to Clojure metadata".

That's a side-effect of under-specification in the protocol and it's mostly related to the names of keys in the responses. The data itself is quite generic, but the names of the keys came from Clojure terminology and in some cases it might be better to change them. Not a big deal for sure, but rather an area for small improvement.

> "We added the other serializer options much later and almost nobody uses them so we must have made the right decision" - there's a huge amount of conceptual inertia when there's a default; the only thing this observation supports is that the default isn't _unpleasant enough_ to compel users to switch.

Perhaps that's just inertia indeed. From my perspective if something is really needed/much better it tends to get used. I can only speculate at this point why the new serializes didn't take off.

Hopefully this follow-up makes my responses a little bit less odd.