News for hackers. Stuff that matters.

A comment on Almost monospaced: the perfect fonts for writing. Parent comment

Re:Almost monospaced: the perfect fonts for writing by thaumasiotes on Monday November 07, 2022 @01:58AM (#33502107)
> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big.

Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this:

    [item1
     ,item2
     ,item3
     ,item4
    ]
instead of a sane way. It means adding or removing an element only changes one line in the diff!

Who cares? It's not hard to understand what's happening in a diff that makes this kind of change. You want the code to be easy to read, not easy to diff.

You could also easily base your diff algorithm on a lexer for the language rather than a lexer for ascii, in which case changing the amount of whitespace would register as "not a change".

[ Parent | on HN ]
Re:Almost monospaced: the perfect fonts for writing by madsohm on Monday November 07, 2022 @02:32AM (#33502383)
Many languages also support a comma after the last item, meaning you can still have one line diffs and have a sane reading structure:

    [
      item1,
      item2,
      item3,
      item4,
    ]
[ Parent | on HN ]
Re:Almost monospaced: the perfect fonts for writing by mikojan on Monday November 07, 2022 @03:42AM (#33502991)
This looks bad. Haskell is much better:

  [ item1
  , item2
  , item3
  , item4
  ]
[ Parent | on HN ]
Re:Almost monospaced: the perfect fonts for writing by thaumasiotes on Monday November 07, 2022 @04:16AM (#33503327)
Compare lisp:

    (item1
     item2
     item3
     item4)
;p
[ Parent | on HN ]
Re:Almost monospaced: the perfect fonts for writing by vore on Monday November 07, 2022 @04:03AM (#33503200)
Leading comma is better at resolving textual 3-way merges, e.g.:

   [ a         [ a       [ a
   , b         , b    /  , b
   , c   -->   , c   /   , c
   , d         , d  /    , dd
   ]           , e       ]
               ]
Your usual 3 way merge algorithm will correctly deduce:

   [ a
   , b
   , c
   , dd
   , e
   ]
Contrast this with trailing comma:

   [ a,         [ a,       [ a,
     b,           b,    /    b,
     c,   -->     c,   /     c,
     d            d,  /      dd
   ]              e        ]
                ]
You now have a merge conflict between "d," and "dd".

However, if you were to require a trailing comma after the final element you wouldn't have this problem.

[ Parent | on HN ]
Re:Almost monospaced: the perfect fonts for writing by Izkata on Monday November 07, 2022 @02:17PM (#33510859)
> Contrast this with trailing comma:

Example doesn't have a trailing comma. If it did, it would act the same as the leading comma.

But also the leading comma just moves the problem to the beginning of the list instead of the end. Trailing comma with the opening [ on its own line wouldn't have that problem anywhere.

[ Parent | on HN ]