Interview with Doug Crockford, creator of JSON | Hacker News Reader

Interview with Doug Crockford, creator of JSON

simple-talk.com

15 pointsalavrik13 comments

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).

In his book, he disavows "creator", and prefers "discoverer".

Yeah, I've also wondered about that.

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.

Wiring some S-Expressions and parsing them, would be more apt than the eval comparsion.

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.

Interesting. If you are working with Python-only, why have you decided against Python pickling?

One reason is debuggability. Being able to see exactly what is persisted and what goes over the wire. Pickles can drag in arbitrarily large object graphs if you are not careful and they are not completely safe from the security point of view.

However, the other reason (the original reason peraps) is that we have some C processes that listen and interpret s-expressions. There were there before Python, so we already had an s-expression library for them. Then our Python processes had to talk to the C so I implemented Python object persistence on top of the existing s-expressions. Now we use it even between Python processes.

Well perhaps one day we'll just switch to json, yaml or protobufs. But we haven't decided which one yet.

I do find it interesting that nobody even mentions s-expression these day when there compare various persistence mechanism. I guess lisp and parantheses have stopped being cool?

When the only thing you have is XML, then S-Expressions are an enlightenment. JSON isn't nearly as moronic, so there's less pain to make you reach for S-Expressions. I guess JSON is good enough.

We use S-Expressions for logging in XenServer.

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.

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).

PS: I'm actually typing this on my MacBook Pro.

Reply on news.ycombinator.com