Hacker News Reader

Comment by zdw | Hacker News Reader

My prediction is that JSON will eventually reach feature parity with XML (this is quite similar to XPath), then we'll dump it for YAML or something.

Great.

View on HN

JSON is almost the simplest untyped text-based tree serialization format that could possibly be designed. In terms of complexity, XML and YAML are closer together.

I'd argue that Lisp s-expressions are simpler.

S-expressions can contain code. Json expressions are data only.

That S-expressions can/often contain code doesn't make them more complicated when used for data only. Anything can contain code.

It isn't that S-expressions can contain code, it's that they are so simple that based on a very simple syntactical rule set certain tokens can be interpreted as code or data and because of that you can easily "tokenize" pieces of "code" to make it "data" and vice versa (that's a really flexible feature). Kind of notable that S-expressions are an integral part of the language and not just a "data format" of the language...

You could easily invent a programming language expressed in JSON literals, it just wouldn't be quite the same as javascript. I'd argue that sexprs are simpler because they only use one container type (alists and plists are merely conventions, not baked into the grammar). However, JSON's omission of the symbol/string distinction is one argument the other way.

Yes, you can, probably not too different in nature to Racket's syntactical sugar with using "[" (square brackets) to make reading the LISP code easier... And yes, your argument for their simplicity is actually what I was trying to express (much less successfully than you did).

That might be a slightly amusing syntactical overlay on Common Lisp. Hash-tables are a bit manky to deal with directly IMO; setting up a reader macro in JSON-esque syntax might be quite usable.

Oddly enough, Steele pretty much already did this as a readtable example in his classic manual (based on xappings and xets from Connection Machine Lisp): http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node192.html#X...

yeah, I noticed that as I worked on implementing the idea last night. :-)

True. I withdraw.

A large amount of JSON is actually valid YAML.

I doubt it ever will. The reason why I use JSON is because it's a very simple data format; when I need more expressive and structured data interchange I always fallback on XML+XSD+XSLT - something JSON will probably never catch up with (because that already exists and why make JSON needlessly complex in order to handle what that kind of stack does?).

I think web developers get caught up in bashing XML a lot for no good reason - just because it isn't directly applicable to a simple RESTful API doesn't mean it isn't incredibly useful, it's meant for machines anyway!

XMLs great promise was that it was human readable. Lo and behold, it is more readable by non-bit-addled humans than whatever binary format is used in COBRA RPC.

But no, XML wasn't meant for machines... its just that people today programatically generate and consume XML far more often than they do it by hand.

Reply on news.ycombinator.com