111–120 of 153 posts
S-expressions are the most logical representation of data structures. “CAR”/“CDR” are not a part of the expression syntax, so this argument against them won’t matter.
So S-expressions suffer a similar problem to XML: there is not a clear way to represent many data structures.
Earlier quoted context omitted.
It would be nice to be able to represent 64-bit ints--and have comments.
"comment-subject-author":"this is a comment, we dont need out of band communication, thats a bug, not a feature"
Earlier quoted context omitted.
With compression, payload size differences aren't that significant, and don't necessarily favour other formats (e.g. almost none of the formats have particularly compact representations of strings, and single decimal digit integer values are common enough that integer fields are not that wasteful in JSON). I totally hear you on serialization/deserialization speed, though it is amazing how inefficient some of the "mac…
Are you including the size of the typically useless HTTP headers when you talk about 'payload size', or just the actual payload in the HTTP request itself? I really mean 'typically useless' in the scenario where the communication is being done internally, not when you're actually communicating over the public internet. There can be quite a bit of wastage in this scenario. I really don't care about the 'Date' header o…
All I'm saying is that while JSON is horribly inefficient for some payloads, the reality is that most serialization formats tend to be efficient for specific kinds of payloads, but still have plenty of common cases they don't attempt to be efficient with. For example, machine readable formats like protobuf, thrift, avro, etc. employ some variation on varint encoding to keep small integers compactly represented, they encode strings relatively inefficiently; They encode field type & number, followed by a varint for length, followed by uncompressed UTF-8 encoded payload... and I've found that if anything it seems once you go through the compression ringer it often isn't much different in terms of space consumption vs. JSON... and sometimes it can be less efficient. Given how often fields end up being encoded as strings (even though they should be enums, ints, etc.), this has resulted in a lot of surprising cases for teams who have tried switching away from JSON to reduce payload sizes. If you cared about efficiency, you'd probably have a special encoding mechanism for short strings, and then a reasonably compact (but fast to parse) representation for longer strings, probably using something like SCSU encoding instead of UTF-8.
Also worth looking are EDN [0] (mentioned briefly under S-Expressions), Transit [1] and Fressian [2][3]. [0] https://github.com/edn-format/edn [1] https://github.com/cognitect/transit-format [2] https://github.com/Datomic/fressian/wiki [3] https://www.youtube.com/watch?v=JArZqMqsaB0&ab_channel=Cloju...
Yeah, the author didn’t specify why he thought EDN wasn’t more than “a good start.” I’m curious what it’s missing!
Earlier quoted context omitted.
The attribute versus child conundrum in XML specification is largely absent in JSON. Ordered versus unordered children is still a puzzle to sort out but more of a special case. In XML, there was always some motherfucker trying to stuff CSV into an attribute. And the difference between ID as specified and ID as implemented lead to a lot of problems, reaching its zenith (or maybe nadir?) in the XML Signature spec.
How would you represent CSV in JSON?
If you need three values use an array (or in xml, child element)
Anything that lists BSON should include the fix: JSONB https://news.ycombinator.com/item?id=7457645
I liked this CBOR vs MsgPack article from a while back (which also talks about size on the wire, not just performance): https://diziet.dreamwidth.org/6568.html SBE (Simple Binary Encoding) also makes some interesting performance claims. My pet peeve with both protobuf and capnp is the lack of an option type; they seem to be designed for languages with type systems that include null, rather than more modern languages…
After half a decade of "better than JSON" mentality, fiddling with thrift, protobufs, custom serialization methods, I came to realize JSON/HTTP is usually the right tool for 90% of jobs.
Provided you never need to use integers > 53 bits, dates, binary data, comments or validate what you're sending or receiving it's totally fine.
JSON Schema http://json-schema.org/ is widely used for things like Swagger / OpenAPI.
I would have expected some mention to https://jsonnet.org/ too, which after a bit of practice can be brilliant.
I'm a huge fan of jsonnet, but this article is specifically about data serialization formats, not configuration languages. It could've been a worthwhile mention though.
On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not sure it’s something anyone > actually wants to use, it’s just going to be one more of > those mistakes of the past. Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes,…
> So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy. Fine, but with for example, Protobuf, you share a .proto file and so there's zero percentage chance of this happening.