3 ms·

This clown doesn't even know what a sentence is. In his first example, he has 1/5 sentences per line. Then he changes it to 1/7 sentences per line, i.e. he move

by Camillo 14y ago

This clown doesn't even know what a sentence is. In his first example, he has 1/5 sentences per line. Then he changes it to 1/7 sentences per line, i.e. he moves away from his supposed "one sentence per line" target. Yes, in the text of the article he admits that maybe he was thinking about clauses, but I have a zero tolerance policy towards objectively wrong titles. And of course, the real solution to the problem of "fussing with the lines of each paragraph so that they all end near the right margin" is to use a text editor that soft-wraps lines. Yes, computers have recently become powerful enough to make that possible while editing the document! Amazing.

jdp 14y ago
The title is One sentence per line, but he clarifies to include clauses in the body of the article. This also has nothing to do with where the margin ends, but editing text in developer formats that is later transformed to end-user formats in a way that gels well with the tools of the Unix environment. Your comment is unnecessarily venomous and not representative of the contents of the article.
- Camillo 14y ago
  Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs? If we stop teaching people to bend over backwards to accomodate 70s technology, maybe we'll have more young hackers fixing our tools.
  - jmmcd 14y ago
    Diffs are only half the picture. Is git able to correctly merge two branches which each have single-word edits to a long-line sentence? I'm pretty sure it's not. I think the article is correctly arguing that we should continue to bend over backwards to accommodate 2012 technology.
  - jdp 14y ago
    > Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs? GitHub's web UI only does a line diff. Which is not particularly helpful when you change a word or two in a six sentence paragraph. It's possible to do a word diff locally of course: `git diff --word-diff` but that's not the general use case for a code host, right now most code is line oriented and the UI suits it well. That is one of the reasons that the article advocates formatting thoughts with newlines, good portability. These input texts are closer to code than prose, so why format it like it was? Splitting thoughts into units digestible by your coding environment has the huge benefit of working with individual thoughts instead of individual paragraphs.

by Camillo 14y ago

jdp 14y ago

The title is One sentence per line, but he clarifies to include clauses in the body of the article. This also has nothing to do with where the margin ends, but editing text in developer formats that is later transformed to end-user formats in a way that gels well with the tools of the Unix environment. Your comment is unnecessarily venomous and not representative of the contents of the article.

Camillo 14y ago
Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs? If we stop teaching people to bend over backwards to accomodate 70s technology, maybe we'll have more young hackers fixing our tools.
- jmmcd 14y ago
  Diffs are only half the picture. Is git able to correctly merge two branches which each have single-word edits to a long-line sentence? I'm pretty sure it's not. I think the article is correctly arguing that we should continue to bend over backwards to accommodate 2012 technology.
- jdp 14y ago
  > Have you noticed how Github helpfully shows which words have changed inside a line when looking at diffs? GitHub's web UI only does a line diff. Which is not particularly helpful when you change a word or two in a six sentence paragraph. It's possible to do a word diff locally of course: `git diff --word-diff` but that's not the general use case for a code host, right now most code is line oriented and the UI suits it well. That is one of the reasons that the article advocates formatting thoughts with newlines, good portability. These input texts are closer to code than prose, so why format it like it was? Splitting thoughts into units digestible by your coding environment has the huge benefit of working with individual thoughts instead of individual paragraphs.