> 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?
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.
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?