<span style="font-family: Arial;">By economy I hope you don't mean financial data, as it is utterly terrible at it. It is terrible at most of everything important really. People only use it because everyone uses it.<br><br>-- <br>Loïc Hoguin<br>http://ninenines.eu</span><span style="font-family: Arial;"><br><br>-------- Original Message --------<br>From:Carsten Bormann <cabo@tzi.org><br>Sent:Sun, 09 Mar 2014 22:15:24 +0100<br>To:Anthony Ramine <n.oxyde@gmail.com><br>Cc:Erlang MailingList <erlang-questions@erlang.org><br>Subject:Re: [erlang-questions] No JSON/MAPS interoperability in 17.0?<br><br></span>> I said around. There is absolutely no tooling around JSON which is properly specified and widely used, that was to reply to the namedropping of ASN.1 and XML.<br><br>Yeah.  JSON is ready to eat.  No ASN.1 compilers or XML schema tools needed.<br><br>> Dominant? Do you have statistics for this? My own experience is that we inject JSON in webpages a lot.<br><br>Indeed, I had the impression that the comments would relate to such a background.<br><br>> Stack Overflow seems to agree.<br><br>Stack Overflow certainly agrees that this usage is problematic and therefore generates a lot of questions about how to remove the bullet from the foot,<br><br>> See above. PHP has some options to counter these problems, Rails has escape_html_entities_in_json.<br><br>PHP has a lot of things that are not needed in Erlang…<br>The Rails people have since learned that generating JavaScript with data values inserted is not such a great idea (the feature is not really about JSON despite its name).<br><br>>>> Just because other languages include such a thing doesn’t mean Erlang should too.<br>>> <br>>> Of course that would be a weak reason.  But it's a straw man.<br>>> The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data.<br>> <br>> Most widely used? In the web probably. In other fields, I wouldn’t bet on this.<br><br>It’s not replacing HDF5.<br>But it is quickly getting rid of CSV, XML, and a ton of ad-hoc syntaxes that together with a bit of spit and string hold together the Economy.<br><br>> Given that there is a myriad of third-party JSON libraries, what’s the problem?<br><br>That *is* the problem.<br>When I need to print a floating-point number, I don’t start looking for and comparing third-party libraries.<br>(Printing floating-point is a problem that is about ten times as difficult as the problem of printing JSON is when you already can print floating point numbers.  It also has more parameters than a JSON printer needs.)<br><br>> And a standard library which sets in stone such a supposedly-important feature the moment a convenient datatype is available isn’t worth anything, in my opinion.<br><br>Well, it’s worth to design it properly then.<br><br><br>The reason I’m reacting to this discussion is that it seems to be dominated by people who have never used JSON for what it is good at.<br>That is not a character flaw, but it may skew the discussion in the wrong direction.<br>(Replace “JSON” with “strings decimally representing floating point numbers” in the previous messages in this thread to find out how ridiculous some of them sound to me.)<br><br>Grüße, Carsten<br><br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br>