3 ms·

i will never stop shilling for EDN: https://github.com/edn-format/edn https://github.com/edn-format/edn it has no comma issues (commas are whitespace), it has

i will never stop shilling for EDN: https://github.com/edn-format/edn https://github.com/edn-format/edn it has no comma issues (commas are whitespace), it has comments, it's very structured, it got better set of primitive types and literals for them, it has native support for tagged values for encoding more complex types, it's got first class support of encoding computation by virtue of being subset of clojure - lists can represent function calls, the usual lisp shenanigans, it has readability of yaml and none of it's drawbacks. it's a shame EDN is not more widely used.

int_19h 8y ago
It does have some questionable Clojure-isms (e.g. why have both vectors and lists), but it's certainly much better than most contenders out there. Unlike JSON, it didn't throw the baby out with the bathwater when it comes to XML features beyond syntax and data model idiosyncrasies - it still has namespaces, for example, making it trivial to design extensible data models.
- keymone 8y ago
  Vectors and lists are very different data structures with different performance characteristics.
  - int_19h 8y ago
    In-memory, yes, but not when it comes to serialization. As data, both are semantically just sequences of values for which order matters. Indeed, you generally don't see this distinction in most serialization formats.
    - keymone 8y ago
      > both are semantically just sequences of values for which order matters you've just described strings, shall we get rid of them too? :) i find it weird that you would complain about presence of some feature which in no way interferes with any other features and can be completely ignored without any consequences. was there something else you wanted to use parens for in EDN serialization format?
      - int_19h 8y ago
        Complexity matters for serialization formats - the more complex the spec is, the harder it is to implement a parser for it, and the larger that parser is. Serialization frameworks can't just ignore features without consequences. Thus, redundant features always draw attention - this is no different than e.g. XML having both attributes and elements, which is also often brought up as one of its deficiencies. But I don't consider it a major deficiency, just a nit. I mean, in the comment that you've responded to, I literally said that it's one of the best contenders for a human-readable serialization format today - it's certainly much better than JSON, or XML for that matter. It's just not perfect.

int_19h 8y ago

It does have some questionable Clojure-isms (e.g. why have both vectors and lists), but it's certainly much better than most contenders out there. Unlike JSON, it didn't throw the baby out with the bathwater when it comes to XML features beyond syntax and data model idiosyncrasies - it still has namespaces, for example, making it trivial to design extensible data models.

keymone 8y ago
Vectors and lists are very different data structures with different performance characteristics.
- int_19h 8y ago
  In-memory, yes, but not when it comes to serialization. As data, both are semantically just sequences of values for which order matters. Indeed, you generally don't see this distinction in most serialization formats.
  - keymone 8y ago
    > both are semantically just sequences of values for which order matters you've just described strings, shall we get rid of them too? :) i find it weird that you would complain about presence of some feature which in no way interferes with any other features and can be completely ignored without any consequences. was there something else you wanted to use parens for in EDN serialization format?
    - int_19h 8y ago
      Complexity matters for serialization formats - the more complex the spec is, the harder it is to implement a parser for it, and the larger that parser is. Serialization frameworks can't just ignore features without consequences. Thus, redundant features always draw attention - this is no different than e.g. XML having both attributes and elements, which is also often brought up as one of its deficiencies. But I don't consider it a major deficiency, just a nit. I mean, in the comment that you've responded to, I literally said that it's one of the best contenders for a human-readable serialization format today - it's certainly much better than JSON, or XML for that matter. It's just not perfect.