Hacker News Reader

Comment by luhn | Hacker News Reader

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.

View on HN

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.

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.

Aside, I’m really excited to move to a newer JDK: https://openjdk.org/jeps/358

Thoughtful application of the Law of Demeter would improve at least half the code examples given. Judicious use of Option<> would help, also.

Python 3.11 provides this information at runtime. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...

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

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

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.

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.

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.

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.

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.

Have you tried patience diff?

See `git help diff`

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.

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.

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)

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.

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)

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.

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

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.

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.

Reply on news.ycombinator.com