4 ms·

One big advantage not mentioned in the article particularly relevant to this audience: git diffs (or your VCS of choice). One sentence per line means diffs wi

by luhn 4y ago

One big advantage not mentioned in the article particularly relevant to this audience: git diffs (or your VCS of choice). One sentence per line means diffs will operate per-sentence, rather than per-paragraph. This way the diff can capture the restructuring of the paragraph (adding/removing/replacing a sentence), which gives much more insight than swapping out the paragraph wholesale. It also means minor changes (e.g. typo fixes) will only add+delete a single sentence, making it much easier to identify what has actually changed from one commit to the next. I take this a step further and will often split out a single sentence into a clause per line, but this is a judgement call rather than a hard and fast rule.

majormajor 4y ago
Many GUI diff tools will do this neatly regardless of whitespace, FWIW, so this hasn't been a motivator for me for code or text.
hinkley 4y ago
I think we need to start changing this. In an era of language servers, perhaps our diff tools should be semantic instead of line based. I get so tired of seeing diffs where I add a function and the diff shows that I added it inside the previous function instead of between them, because it starts the diff one line too early.
- dahfizz 4y ago
  Yes! I find `git diff` to be the most annoying thing about git. I can be pretty forgiving of the clunky UX, but the diff output is just wrong. People often say of git, "The porcelain is bad but the plumbing is good". The opposite is true for digging, IMO.
  - sangnoir 4y ago
    Fortunately, git permits the use of external difftools. One can easily configure git to use their preferred semantic diff tool and git wouldn't even care. The plumbing is excellent.
  - account42 4y ago
    Well, `git diff` is part of the porcelain. The git model doesn't work on diffs, it works with complete trees (sometimes stored as deltas, but that is an implementation detail). Diffs are for the user because they make it easier to see the difference compared to just having the old and new copy show. There is nothing preventing git diff from being changed to use semantic information when calculating the diffs shown.
  - butterNaN 4y ago
    I have configured git to use `vimdiff`, based on advise I saw on the Internet some time ago: git config --global diff.tool vimdiff git config --global difftool.prompt false Typing `git difftool` yields the expected behavior. :qa in vim cycles to the next file in the changeset without saving anything. Also, by default, git calls vimdiff with the -R option. You can override it with git config --global difftool.vimdiff.cmd 'vimdiff "$LOCAL" "$REMOTE"' This will open vimdiff in writeable mode which allows edits while diffing. :wq in vim cycles to the next file in the changeset with changes saved.
- Groxx 4y ago
  Debuggers and stack traces too. Logic is not line-based. When you get a NPE on a line containing `thing.method(x.y.z, q(), w.e().rty())`, which item is it on? Type information is insufficient, there could be multiple of the same thing on the same line. Some debuggers are smarter ("step to cursor" sometimes goes to in-line locations), but many are not, and most languages I've seen will give you precise compile-time error locations, but at runtime all you get is lines. Lines suck.
  - btgeekboy 4y ago
    Aside, I’m really excited to move to a newer JDK: https://openjdk.org/jeps/358 https://openjdk.org/jeps/358
    - cratermoon 4y ago
      Thoughtful application of the Law of Demeter would improve at least half the code examples given. Judicious use of Option<> would help, also.
  - Loranubi 4y ago
    Python 3.11 provides this information at runtime. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-error-locations-in-tracebacks https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...
- emmelaich 4y ago
  Have you tried patience diff? See `git help diff`
- spiffytech 4y ago
  I recently switched my git diff viewer to difftastic, which does semantic diffing. It works pretty well, though it's only useful for viewing diffs, not generating patches.
- spartanatreyu 4y ago
  The problem with diffing goes further than most people think. It's not a problem itself, it's a symptom of a deeper problem: we represent all of our code as plain text. We have built almost everything around plain text, for a long time now. The few things that aren't built around plain text tend to require either proprietary software or open software that seldom lasts more than a decade. Yes, plain text has impressive strengths (see: https://news.ycombinator.com/item?id=30521545 https://news.ycombinator.com/item?id=30521545) but it may be holding some areas back. There has always been talk of smarter diffing tools (new diff algorithms, syntax aware diffing, semantic diffing) but it tends to get hamstrung around supporting plain text. Usually the approaches go with one of two ways. Either: 1. a diffing algorithm has a smarter diffing algorithm than what we already have, until it gets into a corner case and ends up worse than what we already have. 2. an LSP-like service goes through the effort of building a full AST to perform diffs with, only to convert everything back to plain text in the end. This makes diffing take longer. The fact that ASTs can't represent some changes and we don't realize until after the work is done doesn't help this. I'd wager that over the next few decades, new languages are going to migrate away from plain text representation and move entirely to AST representations. ASTs can be perfectly diffed, and only writing code as an AST means that it'll be impossible to write some kinds of code that is almost correct. There's a few academic research languages around this, but I think one of the more interesting explorations with this kind of AST only development styles has to be by Dion Systems: https://dion.systems/blog_0001_hms2020.html https://dion.systems/blog_0001_hms2020.html They basically acknowledge that we as developers are not going to move to a new AST-based tool if it's not going to work with our other tools, so they want to experiment across the development workflow to see how well ASTs can work across the development space. Their 2020 talk about this was fascinating: https://vimeo.com/485177664 https://vimeo.com/485177664
  - account42 4y ago
    There is nothing preventing you from pretending that a source file is not plain text but rather a bespoke AST encoding that just happens to look like plain text. The only advantage to using a different AST encoding is parsing speed that that by no means offsets the enourmous advantages that a plain text encoding gives you for something that is edited by humans.
- jeanfrg 4y ago
  This is such a great point. Diffs have largely not changed in decades and increasing the quality of diffs by 10% i feel would contribute so much to productivity. Especially when files contain repeating lines between chunks of code diffs tend to find it hard to understand what was deleted and what was moved because of the deletion.
FullyFunctional 4y ago
It's mentioned by Mihail Milchev in comment #13. I say that exactly because this is the reason I've been doing this for years myself.
blt 4y ago
I also use one clause per line in long sentences. It makes it easier to try different ways of structuring the same information. You can do major edits with little more than whole-line copy and paste, capitalization changes at line beginnings, and punctuation changes at line endings -- all of which are easy in vim (dd/p, 0~, $r/$x/A)
_tom_ 4y ago
You could write normally and then split on sentence boundaries with any NLP tool. Then pipe the output into a diff. Don't format your writing to suit your tools. Hacker news today says that OpenNLP 2.0 just came out. That should work.
ivansavz 4y ago
RE diff: you should try `git diff --color-words` it's very good for diffing text (output is similar to output of latexdiff: red = word removed, blue = word added)
layer8 4y ago
> One sentence per line means diffs will operate per-sentence, rather than per-paragraph. It isn’t necessary to have each sentence on a single line in order to achieve that. It’s sufficient to have a line break after each sentence, but you may also have additional line breaks in the middle of a sentence. That’s how I format plain text when diffs are relevant. Sometimes it also makes sense to not have a line break between closely related (and possibly short) sentences. In the end it’s the semantic coherent unit of thought that counts, not the syntactical sentence-ending period or full stop.
speleding 4y ago
Another advantage not mentioned: it helps you avoid overly long sentences. I use this technique and have a habit of rambling on. If I hit the right margin of my text editor I know I should try to split the sentence.

by luhn 4y ago

majormajor 4y ago

Many GUI diff tools will do this neatly regardless of whitespace, FWIW, so this hasn't been a motivator for me for code or text.

hinkley 4y ago

I think we need to start changing this. In an era of language servers, perhaps our diff tools should be semantic instead of line based. I get so tired of seeing diffs where I add a function and the diff shows that I added it inside the previous function instead of between them, because it starts the diff one line too early.

dahfizz 4y ago
Yes! I find `git diff` to be the most annoying thing about git. I can be pretty forgiving of the clunky UX, but the diff output is just wrong. People often say of git, "The porcelain is bad but the plumbing is good". The opposite is true for digging, IMO.
- sangnoir 4y ago
  Fortunately, git permits the use of external difftools. One can easily configure git to use their preferred semantic diff tool and git wouldn't even care. The plumbing is excellent.
- account42 4y ago
  Well, `git diff` is part of the porcelain. The git model doesn't work on diffs, it works with complete trees (sometimes stored as deltas, but that is an implementation detail). Diffs are for the user because they make it easier to see the difference compared to just having the old and new copy show. There is nothing preventing git diff from being changed to use semantic information when calculating the diffs shown.
- butterNaN 4y ago
  I have configured git to use `vimdiff`, based on advise I saw on the Internet some time ago: git config --global diff.tool vimdiff git config --global difftool.prompt false Typing `git difftool` yields the expected behavior. :qa in vim cycles to the next file in the changeset without saving anything. Also, by default, git calls vimdiff with the -R option. You can override it with git config --global difftool.vimdiff.cmd 'vimdiff "$LOCAL" "$REMOTE"' This will open vimdiff in writeable mode which allows edits while diffing. :wq in vim cycles to the next file in the changeset with changes saved.
Groxx 4y ago
Debuggers and stack traces too. Logic is not line-based. When you get a NPE on a line containing `thing.method(x.y.z, q(), w.e().rty())`, which item is it on? Type information is insufficient, there could be multiple of the same thing on the same line. Some debuggers are smarter ("step to cursor" sometimes goes to in-line locations), but many are not, and most languages I've seen will give you precise compile-time error locations, but at runtime all you get is lines. Lines suck.
- btgeekboy 4y ago
  Aside, I’m really excited to move to a newer JDK: https://openjdk.org/jeps/358 https://openjdk.org/jeps/358
  - cratermoon 4y ago
    Thoughtful application of the Law of Demeter would improve at least half the code examples given. Judicious use of Option<> would help, also.
- Loranubi 4y ago
  Python 3.11 provides this information at runtime. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-error-locations-in-tracebacks https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...
emmelaich 4y ago
Have you tried patience diff? See `git help diff`
spiffytech 4y ago
I recently switched my git diff viewer to difftastic, which does semantic diffing. It works pretty well, though it's only useful for viewing diffs, not generating patches.
spartanatreyu 4y ago
The problem with diffing goes further than most people think. It's not a problem itself, it's a symptom of a deeper problem: we represent all of our code as plain text. We have built almost everything around plain text, for a long time now. The few things that aren't built around plain text tend to require either proprietary software or open software that seldom lasts more than a decade. Yes, plain text has impressive strengths (see: https://news.ycombinator.com/item?id=30521545 https://news.ycombinator.com/item?id=30521545) but it may be holding some areas back. There has always been talk of smarter diffing tools (new diff algorithms, syntax aware diffing, semantic diffing) but it tends to get hamstrung around supporting plain text. Usually the approaches go with one of two ways. Either: 1. a diffing algorithm has a smarter diffing algorithm than what we already have, until it gets into a corner case and ends up worse than what we already have. 2. an LSP-like service goes through the effort of building a full AST to perform diffs with, only to convert everything back to plain text in the end. This makes diffing take longer. The fact that ASTs can't represent some changes and we don't realize until after the work is done doesn't help this. I'd wager that over the next few decades, new languages are going to migrate away from plain text representation and move entirely to AST representations. ASTs can be perfectly diffed, and only writing code as an AST means that it'll be impossible to write some kinds of code that is almost correct. There's a few academic research languages around this, but I think one of the more interesting explorations with this kind of AST only development styles has to be by Dion Systems: https://dion.systems/blog_0001_hms2020.html https://dion.systems/blog_0001_hms2020.html They basically acknowledge that we as developers are not going to move to a new AST-based tool if it's not going to work with our other tools, so they want to experiment across the development workflow to see how well ASTs can work across the development space. Their 2020 talk about this was fascinating: https://vimeo.com/485177664 https://vimeo.com/485177664
- account42 4y ago
  There is nothing preventing you from pretending that a source file is not plain text but rather a bespoke AST encoding that just happens to look like plain text. The only advantage to using a different AST encoding is parsing speed that that by no means offsets the enourmous advantages that a plain text encoding gives you for something that is edited by humans.
jeanfrg 4y ago
This is such a great point. Diffs have largely not changed in decades and increasing the quality of diffs by 10% i feel would contribute so much to productivity. Especially when files contain repeating lines between chunks of code diffs tend to find it hard to understand what was deleted and what was moved because of the deletion.

FullyFunctional 4y ago

It's mentioned by Mihail Milchev in comment #13. I say that exactly because this is the reason I've been doing this for years myself.

blt 4y ago

I also use one clause per line in long sentences. It makes it easier to try different ways of structuring the same information. You can do major edits with little more than whole-line copy and paste, capitalization changes at line beginnings, and punctuation changes at line endings -- all of which are easy in vim (dd/p, 0~, $r/$x/A)

_tom_ 4y ago

You could write normally and then split on sentence boundaries with any NLP tool. Then pipe the output into a diff. Don't format your writing to suit your tools. Hacker news today says that OpenNLP 2.0 just came out. That should work.

ivansavz 4y ago

RE diff: you should try `git diff --color-words` it's very good for diffing text (output is similar to output of latexdiff: red = word removed, blue = word added)

layer8 4y ago

> One sentence per line means diffs will operate per-sentence, rather than per-paragraph. It isn’t necessary to have each sentence on a single line in order to achieve that. It’s sufficient to have a line break after each sentence, but you may also have additional line breaks in the middle of a sentence. That’s how I format plain text when diffs are relevant. Sometimes it also makes sense to not have a line break between closely related (and possibly short) sentences. In the end it’s the semantic coherent unit of thought that counts, not the syntactical sentence-ending period or full stop.

speleding 4y ago

Another advantage not mentioned: it helps you avoid overly long sentences. I use this technique and have a habit of rambling on. If I hit the right margin of my text editor I know I should try to split the sentence.