5 ms·

JSON, like XML, is supported by everything, including not only general purpose languages, but also by more specialized environments like MATLAB. Also its compat

by ansgri 9y ago

JSON, like XML, is supported by everything, including not only general purpose languages, but also by more specialized environments like MATLAB. Also its compatibility across implementations is very good, excluding support for comments and nonfinite numbers. Contrary to YAML, I mean; there's little reason to use XML except for legacy or markup purposes. JSON-schema implementations are also rather widely available. In performance-sensitive machine-to-machine applications, I agree, better to use someting compiled, but for general-purpose interoperation and archive data storage (where you cannot know when and with what tool you'll want to open it), I've yet to see a compelling alternative.

wirrbel 9y ago
CBOR or MsgPack are binary JSON-like encodings. ProtoBuf depend on the schema definitions and encoder/decoder generation. Without the schema, you cannot read the format (theoretically), if you want your data to be read easily, JSON or CBOR or MsgPack are your best options.
- ithkuil 9y ago
  Encoding/decoding of protobufs can be done dynamically if you know the schema.
  - wirrbel 9y ago
    knowing the schema also means knowing the right revision of the schema. If you store messages for a while, this already can be a problem.
    - ithkuil 9y ago
      schemaless is never really schemaless: the code that accesses your data is implicitly assigning it a schema, so you'll have the same problem. FWIW, protobuf schemas are designed to be friendly for back and forward compatibility; unknown fields can be ignored and "required fields are generally considered harmful", interesting read: https://github.com/google/protobuf/issues/2497 https://github.com/google/protobuf/issues/2497
- RantyDave 9y ago
  I've been using cbor with python and it's been just fantastic. In particular it: Can send a "None"; Can tell the difference between bytes and unicode; and is real fast.
Derbasti 9y ago
To be fair, MATLAB only added support for reading/writing JSON this very year. And they represent JSON objects as structs, which don't support all key names, and they have a very "idiomatic" idea of which JSON arrays are decoded as matrices or cells, and how nested arrays sometimes result in nested arrays, and sometimes result in multi-dimensional arrays. And there's an uneasy relationship between the empty array and Null. It is kind of a mess, really.
- ansgri 9y ago
  I remember my colleague working with JSON in MATLAB via some thirdparty library about 2 or 3 years ago. It was regex-based, it was slow as hell but at least it was available.
  - Derbasti 9y ago
    Fun fact, I wrote my own JSON reader/writer in pure MATLAB, and it is also regex-based, and in many cases, it is faster than MATLAB's own, Mex-based JSON reader/writer: https://github.com/bastibe/transplant https://github.com/bastibe/transplant There are few things as slow as non-vectorized MATLAB code. MATLAB's regex engine is pretty decent, actually, and supports quite a few fancy tricks. For example, I use the regex engine to find the start/end of all numbers and strings ahead of time, and for replacing escape sequences (even unicode escapes!) with their literal characters. The former is particularly important because otherwise, you'd have to manually iterate over characters until you find the end of strings or numbers, which is unacceptably slow in MATLAB.
- radarsat1 9y ago
  Also to be fair, although I can see some uses for supporting JSON in MATLAB, it makes a lot more sense if you're using an array language to use an array-oriented format such as HDF5, which has been supported in all the major numerical platforms for quite a while.
- sundarurfriend 9y ago
  > It is kind of a mess, really. Honestly, that statement applies to pretty much any part of MATLAB unless the behaviour is nailed down by existing mathematical or engineering specifications - and I'm talking as someone that likes MATLAB overall. Mathworks tries a bit to polish and paint it as a coherent whole, but it's patchwork of things built upon and stuck to the sides of the existing structure, optimizing towards a particular kind of "pragmatism" than towards any kind of elegance.
falcolas 9y ago
> there's little reason to use XML except for legacy or markup purposes. There's also the ability to easily and explicitly encode data that doesn't fit to JSON's limited types. A non-exhaustive example includes: sets, hash tables that don't use string keys, tuples, imaginary numbers, fractional numbers, and precision decimal numbers. There's also the fact that XML explicitly supports streaming interpolation of documents, something which can speed up interactivity quite dramatically.

by ansgri 9y ago

wirrbel 9y ago

CBOR or MsgPack are binary JSON-like encodings. ProtoBuf depend on the schema definitions and encoder/decoder generation. Without the schema, you cannot read the format (theoretically), if you want your data to be read easily, JSON or CBOR or MsgPack are your best options.

ithkuil 9y ago
Encoding/decoding of protobufs can be done dynamically if you know the schema.
- wirrbel 9y ago
  knowing the schema also means knowing the right revision of the schema. If you store messages for a while, this already can be a problem.
  - ithkuil 9y ago
    schemaless is never really schemaless: the code that accesses your data is implicitly assigning it a schema, so you'll have the same problem. FWIW, protobuf schemas are designed to be friendly for back and forward compatibility; unknown fields can be ignored and "required fields are generally considered harmful", interesting read: https://github.com/google/protobuf/issues/2497 https://github.com/google/protobuf/issues/2497
RantyDave 9y ago
I've been using cbor with python and it's been just fantastic. In particular it: Can send a "None"; Can tell the difference between bytes and unicode; and is real fast.

Derbasti 9y ago

To be fair, MATLAB only added support for reading/writing JSON this very year. And they represent JSON objects as structs, which don't support all key names, and they have a very "idiomatic" idea of which JSON arrays are decoded as matrices or cells, and how nested arrays sometimes result in nested arrays, and sometimes result in multi-dimensional arrays. And there's an uneasy relationship between the empty array and Null. It is kind of a mess, really.

ansgri 9y ago
I remember my colleague working with JSON in MATLAB via some thirdparty library about 2 or 3 years ago. It was regex-based, it was slow as hell but at least it was available.
- Derbasti 9y ago
  Fun fact, I wrote my own JSON reader/writer in pure MATLAB, and it is also regex-based, and in many cases, it is faster than MATLAB's own, Mex-based JSON reader/writer: https://github.com/bastibe/transplant https://github.com/bastibe/transplant There are few things as slow as non-vectorized MATLAB code. MATLAB's regex engine is pretty decent, actually, and supports quite a few fancy tricks. For example, I use the regex engine to find the start/end of all numbers and strings ahead of time, and for replacing escape sequences (even unicode escapes!) with their literal characters. The former is particularly important because otherwise, you'd have to manually iterate over characters until you find the end of strings or numbers, which is unacceptably slow in MATLAB.
radarsat1 9y ago
Also to be fair, although I can see some uses for supporting JSON in MATLAB, it makes a lot more sense if you're using an array language to use an array-oriented format such as HDF5, which has been supported in all the major numerical platforms for quite a while.
sundarurfriend 9y ago
> It is kind of a mess, really. Honestly, that statement applies to pretty much any part of MATLAB unless the behaviour is nailed down by existing mathematical or engineering specifications - and I'm talking as someone that likes MATLAB overall. Mathworks tries a bit to polish and paint it as a coherent whole, but it's patchwork of things built upon and stuck to the sides of the existing structure, optimizing towards a particular kind of "pragmatism" than towards any kind of elegance.

falcolas 9y ago

> there's little reason to use XML except for legacy or markup purposes. There's also the ability to easily and explicitly encode data that doesn't fit to JSON's limited types. A non-exhaustive example includes: sets, hash tables that don't use string keys, tuples, imaginary numbers, fractional numbers, and precision decimal numbers. There's also the fact that XML explicitly supports streaming interpolation of documents, something which can speed up interactivity quite dramatically.