Skip to: categories | main content

[2010-10-10 09:19]

Why JSON sucks.

JSON sucks. Don't get me wrong, I love the simplicity of it. It's simple, it's easy, it's portable, it's ubiquitous at this point. None of that means it doesn't suck. Outside of Javascript (hence the portability), JSON itself is limited to native types in the grammar:

  • null
  • object (like a hash)
  • array
  • string
  • integer (signed 32bit)
  • number (double)
  • boolean

Really? It's 2010 and we're all flocking to a grammar where we can only accurately represent integers up to 231-1. WTF? Any new standard we adopted should certainly have had grammar specifications for: 1, 8, 16, 32, 64, 128 bit signed and unsigned integers, 32bit and 64bit IEEE floating point (float and double) as well as arbitrary precision real numbers. I'd much rather have a grammar that I struggle to translate into my native language data types (like, "hmmm, what am I supposed to do with a real in C?") than I would have a grammar in which I cannot precisely express myself.

Every time I need to (correctly) represent a large integer such as 4611686018427387900, I'm forced to do so in a string. It causes me to throw up in mouth a little. Everyone seems dead set on this, so I suppose I'll learn to cherish the flavor of bile.

Damaged Bits, OpenSolaris, PostgreSQL Comments: (7) Trackbacks: (0)
Bookmark Why JSON sucks. at del.icio.us Digg Why JSON sucks. Bloglines Why JSON sucks. Fark this: Why JSON sucks. Bookmark Why JSON sucks. at Furl.net Bookmark Why JSON sucks. at reddit.com Bookmark Why JSON sucks. at Ma.gnolia.com

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

David Fetter said,

Sunday, October 10. 2010 at 11:01 (Reply)

Perhaps you'd like to consider adding these things to the spec. I get that this might take some time, but it could well be worth your while.

David Fetter said,

Sunday, October 10. 2010 at 11:07 (Reply)

Looking at this a little further, I'm not seeing anything in the JSON spec that forbids longer numbers. Are you sure you're not referring to the limits of some specific JSON library?

jasong_at_apache said,

Sunday, October 10. 2010 at 11:50 (Reply)

As far as I know there is no 32 bit restriction in the JSON specification itself per say, but JS may be the issue. Why not use some big number approach? It 'should' be faster/smaller during runtime.

For reference:

From: RFC4627, Section I - Introduction

"It is derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard"

From ECMA 262:

8.5 The Number Type

"The Number type has exactly 18437736874454810627 (that is, 264−253+3) values, representing the double- precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 253−2) distinct “Not-a-Number” values of the IEEE Standard are represented in ECMAScript as a single special NaN value..."

Pedro Melo said,

Monday, October 11. 2010 at 06:54 (Link) (Reply)

As jasong_at_apache, I think you are wrong about the size of the "numbers" in JSON.

But assuming that you are right, what would be your proposed alternative?

jauco said,

Monday, October 11. 2010 at 07:20 (Reply)

from the specs:2.4. Numbers

The representation of numbers is similar to that used in most programming languages. A number contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part.

Octal and hex forms are not allowed. Leading zeros are not allowed.

A fraction part is a decimal point followed by one or more digits.

An exponent part begins with the letter E in upper or lowercase,

which may be followed by a plus or minus sign. The E and optional

sign are followed by one or more digits.

Numeric values that cannot be represented as sequences of digits

(such as Infinity and NaN) are not permitted.

number = [ minus ] int [ frac ] [ exp ]

decimal-point = %x2E ; .

digit1-9 = %x31-39 ; 1-9

e = %x65 / %x45 ; e E

exp = e [ minus / plus ] 1*DIGIT

frac = decimal-point 1*DIGIT

int = zero / ( digit1-9 *DIGIT )

minus = %x2D ; -

plus = %x2B ; +

zero = %x30 ; 0

I don't see a maxInt specification here. It doesn't say anything about the way numbers are stored. It only specifies that they should be presented as decimals (so 1/3 or Pi can't be accurately represented)

I think your library is the culprit.

jauco said,

Monday, October 11. 2010 at 07:22 (Reply)

btw, your live preview != end result

Theo Schlossnagle said,

Monday, October 11. 2010 at 10:49 (Link) (Reply)

I suppose I was too loose with JSON itself. JSON, in my opinion is ruled by ECMAScript. ECMAscript restricts numbers to be of type IEEE 64bit floating point. This is entirely insufficient.

The problem is that I can't represent very very large integers with precision. Either (a) they get converted to some imprecise type or (b) they produce a syntax error in ECMAScript implementations.


Add Comment