Interview with Doug Crockford, creator of JSON (opens in new tab)

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.

You must not be an Apple fan.

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.