I don't understand you. Forcing trailing commas is one of the best features of Go, it enforces consistency where you must have a comma at the end of the line. Re-orderding lines? No worries, all of them have commas. Removing a line? No comma to change anywhere

No trailing commas is actually INconsistent, consistency is when every element ends with a comma

You've also got it backwards on quotes, it complicates writing by forcing you to write more. And with "Especially when automation exists" wondering is a non-issue, you'd get the syntax hint/error right there while typing and see if you need quotes before anything breaks

The problem I have with trailing commas for the last entry is that it's missing one key bit of information: the last entry is supposed to be the last entry in the list. Whenever I see a list where the last entry has a trailing comma I wonder if someone copy-pasted only part of the list or something. Having to add a comma when appending to the list doesn't seem that bad to me as a trade off.

The last entry already has an indicator - like a closing bracket.

> Having to add a comma when appending to the list doesn't seem that bad to me as a trade off.

Then do that! No one is forcing you to add trailing commas, they're optional and for all the other people who don't think they add value

If you already have quotation marks, what's the point of the commas?

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

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.

Oh, actually that is the syntax I will use for writing abstractions:

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

I don't think

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

would be better. Indentation and/or coloring my-abstr and the labels (foo:, baz:, quux:, lol:) are the right measures here.

While I have no problems with indentation based syntax, it's not very conductive to minimization, so it's a no go for JSON's case.

Coloring things is a luxury, and from my understanding not many people understand that fact. When you work at the trenches you see a lot of files on a small viewport and without coloring most of the time. Being able to parse an squiggly file on a monochrome screen just by reading is a big plus for the file format in question.

As technology progresses we tend to forget where we came from and what are the fallbacks are, but we shouldn't. Not everyone is seeing the same file in a 30" 4K/8K screen with wide color gamut and HDR. Sometimes a 80x24 over some management port is all we have.

Sure, color and indentation are optional, but even without those, I don't see that a comma in the above syntax helps much, even on a 80x24 monochrome display. If you want separators, note that the labels which end with a colon are just that, and just as clear as commas. There is a reason why you tried to obfuscate that in your example by placing the colons not with the labels, but the arguments.

You can also remove the commas in the arrays.

You could, there is no fixed syntax for arrays in Practal, so it would depend on which custom syntax becomes popular. But for expressions that are bracketed anyway, it makes sense to have commas (or other separators), because otherwise you write something like

    [(a b) (x y)]

instead of

    [a b, x y]

Personally, i like the second option better.

Looks easy to parse to me and you could also remove the commas in the array.

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