

Interview with Doug Crockford, creator of JSON - alavrik
http://www.simple-talk.com/opinion/geek-of-the-week/doug-crockford-geek-of-the-week/

======
docgnome
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.

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

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

~~~
jerf
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.

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

~~~
rdtsc
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.

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

~~~
rdtsc
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?

~~~
eru
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.

