[erlang-questions] No JSON/MAPS interoperability in 17.0?

Carsten Bormann <>
Sun Mar 9 22:15:24 CET 2014


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

Yeah.  JSON is ready to eat.  No ASN.1 compilers or XML schema tools needed.

> Dominant? Do you have statistics for this? My own experience is that we inject JSON in webpages a lot.

Indeed, I had the impression that the comments would relate to such a background.

> Stack Overflow seems to agree.

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,

> See above. PHP has some options to counter these problems, Rails has escape_html_entities_in_json.

PHP has a lot of things that are not needed in Erlang…
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).

>>> Just because other languages include such a thing doesn’t mean Erlang should too.
>> 
>> Of course that would be a weak reason.  But it's a straw man.
>> The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data.
> 
> Most widely used? In the web probably. In other fields, I wouldn’t bet on this.

It’s not replacing HDF5.
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.

> Given that there is a myriad of third-party JSON libraries, what’s the problem?

That *is* the problem.
When I need to print a floating-point number, I don’t start looking for and comparing third-party libraries.
(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.)

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

Well, it’s worth to design it properly then.


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.
That is not a character flaw, but it may skew the discussion in the wrong direction.
(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.)

Grüße, Carsten




More information about the erlang-questions mailing list