Why BENCODE has been used for transporting clojure code to nrepl in CIDER?

Question

Why can't we simply convert Clojure code to string and send it over TCP and evaluate on the other side(nrepl)?

For example : This is a hashmap {"foo" "bar", 1 "spam"} whose BENCODE encoding is d3:foo3:bari1e4:spame.

If we convert it to string -> {\"foo\" \"bar\", 1 \"spam\"}

and evaluate on the other side instead of using BENCODE as shown below.

(eval (read-string "{\"foo\" \"bar\", 1 \"spam\"}"))
; ⇒ {"foo" "bar", 1 "spam"}

I am new to the Clojure world. This might be a stupid question but anyway.

Answer 1

For people looking for the answer, read the # Motivation section in https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/bencode.clj

This is very well written.

Answer 2

nREPL's maintainer here. There are several reasons why nREPL uses bencode by default:

• We needed a data format that supports data streaming easily (you won't find many streaming JSON parsers)
• We needed a data format that could easily be supported by many clients (support for formats like JSON and EDN is tricky in editors like Emacs and vim). I can tell you CIDER would not have existed if 8 years ago we had to deal with JSON there. :-)
• Bencode is so simple that usually you don't even need to rely on a third-party library for it (many clients/servers have their own implementation of the encoding/decoding in less than 100 lines of code) - this means means that clients/servers have one less 3rd party library. Tools like nREPL can't really have runtime deps, as they conflict with the user application deps.
• EDN didn't exist back when nREPL was created

Btw, these days nREPL supports EDN and JSON (via the fastlane library) as well, but I think that bencode is still the best transport in most cases.