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

The rise and rise of JSON (2017)

twobithistory.org

Post reply on HN
Print view View original

91–100 of 107 posts

Re: The rise and rise of JSON (2017)

#91

Post by taeric »

tannhaeuser wrote: post #64
taeric wrote: post #24

Earlier quoted context omitted.

Oddly, attributes do little to actually help you here. What mattered was that xml gave you a language that could describe a valid document. Which, for reasons that actually exist, wasn't necessarily a valid xml document. That said, the effort to write a valid schema was rather high. And it was sold with the other technologies that were in violation of the anti-fragile spirit of the web. That left us with people wanti…

JSON was just a quick shot by Douglas Crockford. No need to spin a genesis myth around it.

I don't know what genesis myth you mean. I do know that I was regularly serializing JavaScript literals for years before I heard of json. Basically just said I could no longer serialize functions. Or references. Which, to be fair, was not that common and I could easily live without.

I do miss being able to have comments.

Re: The rise and rise of JSON (2017)

#92

Post by kazinator »

jcelerier wrote: post #61
taeric wrote: post #4

Earlier quoted context omitted.

You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)

> (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...) I just checked an a comma is a grand total of three filled pixels on my coding font in my screen while a parenthese is 12 pixels. Parentheses are freakin visual bloat. Just look at this : https://i.imgur.com/UTGjbI5.png

> Parentheses are freakin visual bloat. Just look at this: https://i.imgur.com/UTGjbI5.png

Not to mention that f and 0.

We should write in Braille; f is just three dots and so is 0. Bonus: they are similar.

Note that parentheses do something, whereas commas are purely gratuitous. You can't just remove the inner parentheses in (1 2 (3 4) 5) without replacing them with something else. (1, 2, (3, 4), 5) is just stupid though.

Re: The rise and rise of JSON (2017)

#93

Post by DonHopkins »

>Though one might think that a contest between data interchange formats would be unlikely to engender death threats, Winer wrote:

>"No doubt I can write a routine to parse [JSON], but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this travesty? Let’s find a tree and string them up. Now."

In retrospect, he should have said: "Let's find a tree and stringify it."

Re: The rise and rise of JSON (2017)

#95

Post by DonHopkins »

asavinov wrote: post #42
WorkLifeBalance wrote: post #32

Earlier quoted context omitted.

XML without schema are a mess. XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular. Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity. Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to…

Typing (enforcing constraints) is an important aspect. But even without typing XML has one fundamental flaw. You are not able to (correctly) represent tuples with attributes which are sets. In XML, tuple attributes are properties, for example: -- object or object Now let us assume that I want to have a list of authors as a property: -- NOT SUPPORTED Therefore, we use a workaround (a crime actually): Me My friend Now…

Even more fun: XML attributes undergo "whitespace normalization"!

https://stackoverflow.com/questions/260436/preserving-attrib...

Re: The rise and rise of JSON (2017)

#96

Post by DonHopkins »

ainar-g wrote: post #55
dragonwriter wrote: post #50

Earlier quoted context omitted.

Pretty much any time I've seen something like this, relevant inner element of the book is: ... ...

Which reminds me of the picture[1] on the cat-v.org section about XML. [1] http://harmful.cat-v.org/software/xml/xml_ascent.png

The article "XML Sucks" containing that Ward Cunningham image is interesting:

http://harmful.cat-v.org/software/xml/

It includes this classic James Clark quote:

“Any damn fool could produce a better data format than XML” – James Clark 2007-04-06

Which Tim Bray discussed in "Any Damn Fool":

https://www.tbray.org/ongoing/When/200x/2007/04/08/James-Cla...

Tim Bray recommended James Clark's Random Thoughts about "Do we need a new kind of schema language?": "If you’re doing original work around the intersection of messaging and programming, you need to read it and think about it."

http://blog.jclark.com/2007/04/do-we-need-new-kind-of-schema...

James Clark writes:

>Some people propose solving the XML-processing problem by adopting an XML-centric processing model, for which the leading technologies are XQuery and XSLT2. The fundamental problem here is the XQuery/XPath data model. I'm not criticizing the WGs' efforts: they've done about as good a job as could be done given the constraints they were working under. But there is no way it can overcome the constraint that a data model based around XML and XSD is just not very good data model for general-purpose computing. The structures of XML (attributes, elements and text) are those of SGML and these come from the world of markup. Considered as general purpose data structures, they suck pretty badly. There's a fundamental lack of composability. Why do we need both elements and attributes? Why can't attributes contain elements? Why is the type of thing that can occur as the content of an element not the same as the type of thing that can occur as a document? Why do we still have cruft like processing instructions and DTDs? XSD makes a (misguided in my view) attempt to add a OO/programming language veneer on top. But it can't solve the basic problems, and, in my view, this veneer ends up making things worse not better.

>I think there's some real progress being made in the programming language world. In particular I would single out Microsoft's LINQ work. My doubts on this are with its emphasis on static typing. While I think static typing is a invaluable within a single, controlled system, I think for a distributed system the costs in terms of tight coupling often outweigh the benefits. I believe this is less of the case if the typing is structural rather than nominal. But although LINQ (or at least newer versions of C#) have introduced some welcome structural typing features, nominal typing is still thoroughly dominant.

>In the Java world, there's been a depressing lack of innovation at the language level from Sun; outside of Sun, I would single out Scala from EPFL (which can run on a JVM). This adds some nice functional features which are smoothly integrated with Java-ish OO features. XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign.

Re: The rise and rise of JSON (2017)

#97

Post by acdha »

donmatito wrote: post #27
ubernostrum wrote: post #22

Earlier quoted context omitted.

The counterpoint here is that a lot of the success of JSON was in presenting an alternative to the then-state-of-the-art, which was basically "here's a small mountain of spec documents explaining how you need at least fifty megabytes of metadata spread out over forty-three separate namespaces' worth of elements to safely send a single string key to someone else with XML". And at the time people insisted JSON could ne…

Or, "worse is better"

Worse is highly subjective: the XML world spent millions of dollars layering on huge amounts of complexity but never made a corresponding investment in having common tools not suck. Things like validation and schemas still have a horrible user experience and then you have things like libxml2 meaning that most of the world can’t use XSLT or XPath features added a decade ago. Similarly, it’s been notoriously hard to find things in the XML world which have quality documentation, examples, or working validators — doubly unfortunate given the complexity of what they expect users to do.

If you have a job to do, JSON is just plain better on almost every count. I remember being excited by XML 1.0 back in the 90s but the fall in popularity is something lots of people worked hard to accomplish by building so many new, more complex things rather than fixing the foundation. The assumption that users will have to learn your standard is almost always wrong.

Re: The rise and rise of JSON (2017)

#98

Post by DonHopkins »

DonHopkins wrote: post #96
ainar-g wrote: post #55

Earlier quoted context omitted.

Which reminds me of the picture[1] on the cat-v.org section about XML. [1] http://harmful.cat-v.org/software/xml/xml_ascent.png

The article "XML Sucks" containing that Ward Cunningham image is interesting: http://harmful.cat-v.org/software/xml/ It includes this classic James Clark quote: “Any damn fool could produce a better data format than XML” – James Clark 2007-04-06 Which Tim Bray discussed in "Any Damn Fool": https://www.tbray.org/ongoing/When/200x/2007/04/08/James-Cla... Tim Bray recommended James Clark's Random Thoughts about "Do we n…

More words from James Clark on JSON: "Yay" and "Sigh"

http://blog.jclark.com/2010/11/xml-vs-web_24.html

>If other formats start to supplant XML, and they support these goals better than XML, I will be happy rather than worried.

>From this perspective, my reaction to JSON is a combination of "Yay" and "Sigh".

>It's "Yay", because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language-independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements. This leaves the developer with three choices, all unappetising:

>live with an inconvenient element/attribute representation of the data;

>descend into XML Schema hell in the company of your favourite data binding tool;

>write reams of code to convert the XML into a convenient data structure.

>By contrast with JSON, especially with a dynamic programming language, you can get a reasonable in-memory representation just by calling a library function.

Re: The rise and rise of JSON (2017)

#99

Post by taeric »

TuringTest wrote: post #35
taeric wrote: post #4

Earlier quoted context omitted.

You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)

That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one. Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.

I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages.

That said, I cede that they are different. I just don't get the hate of parens.

Re: The rise and rise of JSON (2017)

#100

Post by sli »

taeric wrote: post #99
TuringTest wrote: post #35

Earlier quoted context omitted.

That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one. Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.

I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages. That said, I cede that they are different. I just don't get the hate of parens.

My frontend builds fail because of trailing commas in the code (by design, so technically a non-issue). At the same time, my editors can balance parens but they can't really do anything but complain about trailing commas. It can't assume it's an issue and "fix" it because I just might not be done writing, yet. My editor can make more and safer assumptions about paren balancing, however, and so it does.

I really have no horse in this race, neither of these things bother me. I just can't help but notice that the paren problem in particular can be easily rectified.

Post reply on HN