He also wrote what is, imho, one of the best programming language books, JavaScript: The Good Parts. (http://oreilly.com/catalog/9780596517748) I found it super handy mostly because he made no claims that JS is the best thing ever. A lot of it sucks and he admits that. Which I found super refreshing from the standard "ZOMG X IS TEH BEST EVAR! USE X AND GOLD COINS WILL FALL FROM THE SKY!" of most programming language books.
I wonder if he minds being called the "creator of JSON"? Yes, he created the standard, but I imagine the notation was really decided by Brendan Eich (author of original JS implementation).
Plus that I see JSON as a minor format, it's not like someone didn't think before: "let's just wire some lisp over a socket and eval it on the other side".
The same about the guy that invented Markdown, another minor microformat that somehow is seen as a great accomplishment in some circles (mostly Reddit).
Creating—or discovering, if you prefer—Markdown and JSON were not great feats of technical accomplishment. They are, however, considerable achievements in data format design. In their respective domains, they provide best-of-breed formats with simple rules [1] that anyone can master in a few minutes.
One of the key insights shared by both formats is the very thing that make people wary about touting them as serious creative accomplishments: they build, very explicitly, on existing user conventions. Markdown was based on the emphases and accents used in email; JSON was based on JavaScript's object notation. They appear obvious because we already know the rules.
[1] Simple for humans, anyway; Markdown isn't straightforward to parse, because of all the edge cases.
JSON is a carefully-chosen subset of what "eval" will actually include, the three major differences being that it specifies the delimiters rigidly (JSON that uses apostrophe-delimited strings is not JSON), it rigidly specifies Unicode (defaulting to UTF-8), and it doesn't permit anything that looks like Javascript code. So, comparing it to "wiring over some Lisp and evaling" it is not accurate, JSON was created for the explicit purpose of not doing that. Previous approaches typically did.
That's what I do. I persist python objects into s-expressions using a c-extension module then parse and un-persist data back to python on the other side. Everyone asks me why I don't just switch to JSON. Well I might one day, I just like S-expression for now and the parser is very small, fast and was easy to implement. I even have references (like Yaml) to persist arbitrary object graphs.
Folks around here recognize and appreciate the true value of constraints in design. In the real world, this is often a tough sell. My boss always wants to have a superset of every feature of every competitors' product. It takes some subtle argumentation to overcome this.
Heh, interesting argument, I haven't looked at it like that.
Although I still see JSON as a great accomplishment not for what it is technically but for the following it has (ie. the social aspect, the actual developers using it).