The problem I always had with XML is that it's not clear how to properly encode typical data.

If I have a structure like this JSON:

  {
    "foo": "bar",
    "nested": {
      "nested_foo": "nested_bar",
    }
  }

Should I do this in XML?

  <foo>
    bar
  </foo>
  <nested>
    <nested_foo>
      nested_bar
    </nested_foo>
  </nested>

Or should I do this?

  <foo>
    bar
  </foo>
  <nested nested_foo="nested_bar"/>

If your goal is to simply encode a data structure that looks more or less like a C-style struct (key/values, arrays, primitives), the concept of attributes on tags is superfluous, and introduces ambiguity in how to serialize something.

To me, JSON is nice because it's essentially the minimum viable way of encoding a C-style struct (floating point behavior notwithstanding.) XML has extras like attributes, schemas, and DTDs, which may be useful, but they come at the cost of having additional syntax (<!DOCTYPE ...>, etc), which is auxiliary to the goal of encoding data structures, and thus makes it no longer as minimal.

To me, JSON's approach of having a separate out-of-band definitions of schema (e.g. JSON schema) is the better approach because it's less opinionated, you only pay for it when you need it, and it doesn't require separate syntax. Leave validation to a validation step, my data is my data.

The exact issue is that JSON's usage spread far beyond "payload."

> It's not code.

package.json has a field literally called 'scripts' where the values are shell one-liners.

That kind of stops working when (for example) your "payload" is configuration in a file where comments may make sense, though.

I'm more partial to YAML for readability, but I don't think JSON configs are an awful anti pattern.

This is true, but it is also true that if someone who didn’t read the documentation or the latest version of it, changes a config parameter that brings down a critical system you are responsible for, your bosses or customers won’t care if it was in the documentation or not.

What about json schema files? Hmmm

That's also how I did it in IRC times, when nothing would actually formatted by this

It still looks good even without any formatting! (And btw. I thought that was the intention of markdown …)

Try parsing this:

    { foo :"bar" baz :"bak" quux :[ a,b,c,d ] lol :9.7E+42 }

Ref: https://www.json.org/json-en.html, but without commas. It's line noise. Commas allow a nice visual anchor.

    my-abstr x y z foo: "bar" baz: "bak" "quak" quux: [a, b, c, d] lol: 9.7E+42

    my-abstr x y z, foo: "bar", baz: "bak" "quak", quux: [a, b, c, d], lol: 9.7E+42

This is a popular question, the most common answer I’ve seen is:

> Commas exist mostly to help JSON be human-readable. They have no real syntactic purpose as one could make their own notation without the commas and it'd work just fine.

https://stackoverflow.com/a/36104693

Elsewhere such commas can be optional, e.g. in clojure: https://guide.clojure.style/#opt-commas-in-map-literals

I like the comma in front for SQL better than at the end but you still have the problem of one of the fields missing a comma, the first field instead of the last but I guess maybe you're more likely to move fields and forget to add/remove a comma at the end.

Who writes trailing commas in sql?In every company I worked with the standard was prefix commas:

<pre><code> var , var2 , var3 , var4 </code></pre>

I recommend writing a function to remove trailing commas from SQL. Big time save.

To add to this, when I went to school for design a long time ago, our typography teacher basically told us to never use underlines if we can use italics instead. It tends to mess with the readability of a paragraph and shifts the visual center of gravity downward, making text more difficult to parse. I assume that’s also why italics and underline seem to be used interchangeably from time to time, since they generally achieve the same goal of emphasizing text in the same semantic manner.

Trailing commas were common in language design long before JSON or even JavaScript existed as it simplifies machine generation of code while being comparatively trivial to handle in a parser, so a net win.

The convenience it offers for diffing is just a manifestation of the positive interaction with grammars and language tools. The convention of humans using trailing commas in lists, along with one item per line, is relatively new, though. Stylistically, this used to be frowned upon as long definition lists made source files longer, slower to scroll through, and worsened code locality from the perspective of someone using, e.g., a 25 row terminal.

Huh, I don't know about that. I find it much more convenient for editing because it means the last item in a list doesn't behave differently when it comes to cut/copy/paste.

It can also help eliminate some editing errors, when copying entries to extend a list or reordering entries.

I prefer leading commas to having a final comma with an empty clause, though some people hate that and they don't really solve all the final-entry issues (they address some of them, but others are just moved to being first-entry issues).

I wonder how much json aware diff representation and merge conflict resolution would remove the need of having the trailing comma

Git is generally insufferable when it comes to these. Diffing YAMLs is even worse, and it gets downright hideous when the specific document you're working with betrays YAML's rules about orderedness (the document is order invariant, while YAML is ordered). In that case, even most semantic diffing tools become unusable. This is a thing with JSON too, arrays are ordered.

I've been recently using dyff [0] to diff YAMLs in an order invariant way, and it's been absolutely liberating. Couldn't help with version control, but it's still night and day.

[0] https://github.com/homeport/dyff

it's also annoying to edit, copy a line, add it to the end of a block. now you need to add a comma to the previous line, and strip off the comma on the new one you added (if you copied it from not the previous line).

Trailing commas avoid having the last item behave differently, but they're easy to accidentally omit when they're optional.

  [ "or"
  , "alternatively"
  , [ "the"
    , "first"
    , "item"
    ]
  , "could"
  , "behave"
  , "differently"
  ]

I feel that, despite its repugnant appearance, this "comma-first" approach is the best tradeoff in languages like JSON where trailing commas are forbidden; the leading `[` is much harder to accidentally omit or insert than the subtle trailing `,`.

Comma-first syntax is especially convenient in SQL, which has the forbidden-trailing-comma problem and several analogous problems. In C if I have a long Boolean conjunction

  if (unpleasantly long boolean expression &&
      another unpleasantly long boolean expression &&
      yet another unpleasantly long boolean expression) {

there are several ways to fix it, such as nesting ifs or factoring the expressions into variables or functions. The "comma-first" approach is also visually unappealing for spacing reasons, requiring two extra spaces after the parenthesis:

  if (  unpleasantly long boolean expression
     && another unpleasantly long boolean expression
     && yet another unpleasantly long boolean expression
     ) {

In SQL, C's alternative approaches are not available, and the "comma-first" style is much more natural:

  where unpleasantly long boolean expression
    and another unpleasantly long boolean expression
    and yet another unpleasantly long boolean expression

I do agree, though, that it's better to design languages to avoid this problem, and I think the way to do that is by using item terminators or item initiators in a list rather than by using item separators. That's what C did for statements with `;`, which was a difference from the ALGOL tradition including Pascal, where `;` was a statement separator, with the unpleasant consequences described in https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas....

In Meta5ix http://www.canonical.org/~kragen/sw/dev3/meta5ixrun.py I experimented with using item initiators for rules in a grammar, like Markdown uses for bulleted lists. I'm not pleased with the rest of the syntactic decisions I tried in Meta5ix, but I do think that one was a good tradeoff; here's about a quarter of the Meta5ix compiler:

    - terms: term ["," {continue $choice} term] @choice
    - term: (factor {else $seq}, output) [factor {assert}, output] @seq
    - factor: string {literal $it}
           , "(" terms ")"
           , "[" @many terms {continue $many} "]"

Note that, while comma-first layout feels like a gross abuse of punctuation with `,`, it's quite common and natural with `|` in grammars and pattern-matches in languages like ML, where an initial `|` is also permitted; here's an excerpt from my port of μKanren to OCaml (http://canonical.org/~kragen/sw/dev3/mukanren.ml):

    let rec walk (s : env) = function
      | Vart (Var x) when Env.mem x s -> walk s (Env.find x s)
      | u -> u

I think that's what I should have used in Meta5ix, and I will if I get around to revising it.

    WHERE TRUE
      AND something
      AND something_else

and -strikethrough-

Interesting. I read it as a bit tongue-in-cheek. But who knows...