Hacker News Reader

Comment by stevage | Hacker News Reader

>Why not bold and _italics_. That would make a lot more sense to me.

Surely _underline_ would make more sense than _italics_. Somewhere I have seen /italics/ in use, but that does look kind of regexpy.

>I dislike that trailing commas are not allowed...There is no need for this and it makes writing out valid JSON more complex.

Trailing commas as a trend emerged after JSON was standardised. And thank god JSON is as well and truly standard as it is.

View on HN

It’s an old convention that underline in a manuscript (handwritten or typewritten) directs the typesetter to use italics (as underlines are basically nonexistent in professional typesetting before the WWW). I expect that this is where the _italics_ thing (which predates Markdown) comes from. (There is precedent for /italics/ and I don’t think it’s unreasonable, but it is much rarer.)

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.

I always preferred Textile over Markdown for reasons like this, so was a little sad when Markdown won the popularity contest.

The trailing comma trend is almost entirely down to line-based diff tools as far as I can tell.

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

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

I'd rather have a format supporting a friendly truth on the ground (on the filesystem) than adding yet another "almost like standard behavior" quirk to tooling.

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

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.

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.

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 `,`. In Emacs I use js3-mode, a hack of js2-mode to support comma-first syntax.

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 a punctuation mark 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.

This still seems to have the problem that the first term behaves differently from the others, and is hence inconvenient for editing operations.

FWIW with SQL multi-line booleans, I tend to do:

    WHERE TRUE
      AND something
      AND something_else

Yes, I agree. That's a nice trick! It's more verbose, which is a tradeoff, maybe a bad one. Too bad `,` doesn't have an identity element the way `and` does, so this doesn't solve the problem in JSON.

Underscore for italics probably has its origins in the use of a solid underline as markup in a manuscript/typescript instructing the typesetter to set that fragment in italics (underscore generally being frowned upon in professionally set material otherwise, I think).

Clearly it should be *bold*, _underline_ and /italics/

and -strikethrough-

~strikethrough~ is pretty well established and far less risky than overloading hyphens.

Reply on news.ycombinator.com