Hacker News Reader

Comment by muzani | Hacker News Reader

JSON.

The way it displays and organizes complex data, better than other standards like CSV or XML. Or the things that use tables.

When I first started programming, I had two favorite ways of storing data - INI and arrays. INI for its elegant key/value style. Arrays were just natural because of the way computers think.

I spent months trying to mold these two things together; how would you actually store key-value things within an array? Do you make an array of pointers that lead to key-value objects? (I used C)

JSON is just this beautiful thing that lets you store data however you want. It's beautiful because it doesn't get in the way. Not only that, but it's a data structure you can understand just by looking at it; you'd have to squint to understand raw XML or a SQL table.

View on HN

It's having a rather half-hearted schema definition language though, and the json-encoding itself contains a few fuzzy corners, lacking important data types, and is to be honest not particulary sophisticated.

On the other hand, it's readable, good enough for most tasks, not overly complex, and it's nicer than XML. That is not a small acomplishment.

Still... I am waiting for ASN.2 ... All good features and ideas from ASN.1 without everything bad, which is rather much too :-)

One good idea from ANS.1 is "criticality", how important a future extension to a protocol is, which means that older participants can still handle newer messages, if they contain no "critical" extensions.

Another good thing is that the encoding is detached from the schema representation, which is too good for people to appreciate. You can use the same schema to send XML, BER (original simple tag-value binary format), PER (no unneccesary bytes are sent), or plain strings. (No JSON yet - at least in the standard)

In that way, it's possible to select encoders that suits the mission. Send human-readable data when size/speed/consistency does not matter, and packed super efficient messages when sending from a space probe. Same schema.

ASN.1 is ugly as hell though, and clearly designed by committee.

JSON is not all its cracked up to be. It is useful, but I find its getting treated as some sort of magical solution to everything in the way that XML was 15 years ago.

I have had to configure various pieces of software in JSON and its a PITA (compared to doing the same sort of thing in Python, or most configuration files actually). Its picky about what quotes you use. Its picky about leaving trailing commas in arrays. Its not particularly readable (compared to YAML or XML). It only has one numerical type.

> JSON is just this beautiful thing that lets you store data however you want.

What if I want to store integers?

Not floats.

Integers.

Store it as a string and write your own math routines.

I don't know why you guys are having trouble with this. \s

Or dates? No one would ever need to store dates or times, right?

Write the dates/times as string in ISO 8601 format.

Can you provide some more context?

    > JSON.stringify(1)
    "1"

Stored without a decimal for free, seems like it'd be up to the receiver to interpret it correctly.

What if you receive it in JS?

    JSON.parse(JSON.stringify(1))
    > 1

Ok, so it parses an int for free too... thus my confusion.

Regardless, you can still override anything it does considering the second argument to both `JSON.parse()` and `JSON.stringify()` allows you to provide your own function for handling the logic as you see fit.

JSON.stringify(9223372036854775807) "9223372036854776000" JSON.stringify(9007199254740993) "9007199254740992"

JSON doesn't support integers for example on my 64bit system it can't support INT_MAX as a value and anything greater then 9007199254740993 might just come out as wrong.

You haven't demonstrated your premise. JSON is a format for storing data, completely separate from the JavaScript language. Try validating this in a JSON validator: { "number" : 9007199254740993 }

It's absolutely valid JSON. What you're seeing happen is that the JavaScript language parses the Numeric Literal 9007199254740993 to a value of the Number type, and this value does not accurately represent the intended number. This is a feature of JavaScript, not JSON.

You can see the JSON spec here: http://json.org It does not talk about number size or type - simply that a number is a series of digits(and other symbols).

The JSON library for JavaScript has an inherent limitation when parsing JSON formatted numbers, because it tries to represent them as the Number type, and the Number type cannot represent large numbers. It is absolutely possible to write a JSON parsing library that parses JSON numbers into strings(example - http://php.net/manual/en/function.json-decode.php with the JSON_BIGINT_AS_STRING option). This does not change what kind of numbers JSON supports(any decimal).

I'm don't understand how JSON is better than XML, edn, toml, or yaml. They all have pros and cons, but if I had to pick one as being beautiful, it wouldn't be json!

Which would you pick? Certainly not xml?

No comment.

Reply on news.ycombinator.com