Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons of JSON

inkdroid.org

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Lessons of JSON

#31

Post by mkramlich »

RyanMcGreal wrote: post #7
olavk wrote: post #6

KISS is not a magic formula, though. The precursor to SOAP was XML-RPC which is very simple. So simple it didn't allow time zones in datetimes, and didn't support characters beyond ASCII in strings. There was no way to extend XML-RPC to support unicode or unambigous datetimes. This basically killed XML-RPC for most of the world. JSON already have problems because there is no datetime format. People need datetimes, so…

The important thing to remember is that sometimes the solution to a problem adds so much overhead that it actually creates a bigger problem than the problem it solved. That has been the fate of SOAP, at least for the vast majority of uses.

That reminds me of that saying I heard about XML:

"Some people have a problem and think they can solve it with XML. Then they have two problems."

Re: Lessons of JSON

#32

Post by 6ren »

> Rather than claiming he invented JSON he instead says he discovered it–almost as if he was a naturalist on an expedition in some uncharted territory.

JSON is part of javascript (it's even right there in the name). Far from uncharted territory, javascript was a deliberate human creation. His contribution was to extract that specific part, and apply it to another problem.

Re: Lessons of JSON

#33

Post by 6ren »

olavk wrote: post #6

KISS is not a magic formula, though. The precursor to SOAP was XML-RPC which is very simple. So simple it didn't allow time zones in datetimes, and didn't support characters beyond ASCII in strings. There was no way to extend XML-RPC to support unicode or unambigous datetimes. This basically killed XML-RPC for most of the world. JSON already have problems because there is no datetime format. People need datetimes, so…

To bring out your implicit point, use the right tool for the job. For a simple job use JSON, for a complex job use XML (and XML schema, XSLT etc). Moreover, the existence of XML keeps JSON simple.

Instead of complex needs motivating people to complicate JSON with hacks, they just use the XML stack. Complicating proposals for JSON (like json schema) don't get traction, because their would-be users already have their complicated needs met.

And... enough grey-beards are around to make this point. I will add that before XML, there was CORBA. XML was hailed as simpler, til people added all the bits that were missing. In the bigger picture, I think everyone is waiting for a replacement for the XML stack that really is genuinely simpler - not just reinventing the same hacks on a different base.

Re: Lessons of JSON

#34

Post by RyanMcGreal »

mkramlich wrote: post #31
RyanMcGreal wrote: post #7

Earlier quoted context omitted.

The important thing to remember is that sometimes the solution to a problem adds so much overhead that it actually creates a bigger problem than the problem it solved. That has been the fate of SOAP, at least for the vast majority of uses.

That reminds me of that saying I heard about XML: "Some people have a problem and think they can solve it with XML. Then they have two problems."

Sidenote: that's actually a reference to a usenet post from 1997 by Jamie Zawinsk, a Netscape engineer and the driving force behind the open-sourcing of the Mozilla codebase. In the original, Zawinski was talking about regex:

> Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Zawinski's post, in turn was a reference to a 1988 sigfile from John Myers, quoting D. Tilbrook:

> Whenever faced with a problem, some people say "Let's use AWK." Now, they have two problems.

You can find a detailed history here:

http://regex.info/blog/2006-09-15/247

Re: Lessons of JSON

#35

Post by olavk »

6ren wrote: post #33
olavk wrote: post #6

KISS is not a magic formula, though. The precursor to SOAP was XML-RPC which is very simple. So simple it didn't allow time zones in datetimes, and didn't support characters beyond ASCII in strings. There was no way to extend XML-RPC to support unicode or unambigous datetimes. This basically killed XML-RPC for most of the world. JSON already have problems because there is no datetime format. People need datetimes, so…

To bring out your implicit point, use the right tool for the job. For a simple job use JSON, for a complex job use XML (and XML schema, XSLT etc). Moreover, the existence of XML keeps JSON simple. Instead of complex needs motivating people to complicate JSON with hacks, they just use the XML stack. Complicating proposals for JSON (like json schema) don't get traction, because their would-be users already have their c…

I am skeptical it is possible to invent a stack which solves the same set of problems as SOAP but is significantly simpler. (I would love to be proven wrong though!)
Post reply on HN