Writing one sentence per line
sive.rs
sive.rs
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.
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.
People often say of git, "The porcelain is bad but the plumbing is good". The opposite is true for digging, IMO.
git config --global diff.tool vimdiff
git config --global difftool.prompt false
: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"'
:wq in vim cycles to the next file in the changeset with changes saved.
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.
See `git help diff`
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
Hacker news today says that OpenNLP 2.0 just came out. That should work.
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.
I did the same thing for some time for papers at university for the same reason. It used to annoy me, because I hate to change for my tools, I rather have my tools support my workflow: There should be a nicer diff for that.
https://practicaltypography.com/one-space-between-sentences....
You wouldn't publish anything with line breaks between sentences either. Double spacing or line breaks both work nicely for semantic purposes because html (or markdown which almost always ends up displayed somewhere as html) will ignore it.
Any print publishing software in the 21st century should be aware that two spaces in a prose text source is a hint for a sentence break, and treat it appropriately. They often apply custom spacing (slightly more than 1, but nowhere close to 2) between sentences anyway. Without the two spaces, they have to algorithmically guess at sentences. You just won't notice when there are sentence detection errors, unless you're a typography fanatic; who's going to notice 1 space instead of 1.2 or whatever the optimum happens to be?
What extra information is encoded by fullstop + 2 spaces?
> Good typography seems to dictate a wider space after a sentence than between words.
You:
> Rendering engines can do anything they want. The question is about source representation only, for semantic purposes.
The thread you’ve commented on is literally about rendering, not source representation and semantics. I agree that you can use a double-space as a sentence delimiter, but we’re currently discussing whether it’s “good typography” to render it that way.
I don't think there's much dispute that two spaces is too much in modern properly rendered prose, so I don't know who "we" is. (And anyone who does think two word spaces is just fine, would probably also agree that it should be configurable and not dependent on two spaces in the source text.)
If there's a text renderer out there that renders two spaces as two word spaces in prose, that should be patched, not writers' brains.
Studies examining whether or not wider spacing between sentences improved readability have been inconclusive.
There is one good reason to use two spaces between sentences, at least for text that's going to be processed automatically. It can be very difficult for software to know whether a given punctuation mark is the end of a sentence or something else, like an abbreviation. GNU Emacs, for example, is (or was) coded to recognize sentences by looking for two spaces after a ., ?, or !.[1]
1 https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...
I couldn't tell you when I switched.
I continued through university while using a computer to type things up, I'm pretty sure my thesis had double spaces after periods, written in WP. Once I graduated I dropped it pretty quickly.
Was there an early version of Word's spell-check-on-the-fly that underlined double spaces, or am I miss-remembering?
I don't remember that and I was a fairly early user of Word going back to DOS days although I rarely use it any longer.
It has not been the norm for German ever.
Edit: Related discussion: https://news.ycombinator.com/item?id=22975299
You are in a maze of twisty little passages, all different. You are in a little maze of twisty passages, all different. You are in a little maze of twisting passages, all different.
You are in a maze of twisty little passages, all different. You are in a[-little-] maze of twisty {+little+} passages, all different. You are in a[-little-] maze of [-twisting-]{+twisty little+} passages, all different.
You are in a {+little+} maze of twisty[-little-] passages, all different. You are in a little maze of twisty passages, all different. You are in a little maze of [-twisting-]{+twisty+} passages, all different.
You are in a {+little+} maze of [-twisty little-]{+twisting+} passages, all different. You are in a little maze of [-twisty-]{+twisting+} passages, all different. You are in a little maze of twisting passages, all different.
Is there really something better? Git is pretty great in general, and prose doesn't seem like there'd be much room for improvement in tooling. I'm not a writer really though, so maybe I'm missing something?
As the above implies, you don't have great version control and some of the process management is manual. But it works well for people accustomed to working that way and it's much more familiar for people who don't regularly use git (or use it at all).
EDIT: Meaning that I think this kind of justification is more interesting since it is meant to affect the process of writing itself.
It turns out, editing was Sonia’s job: she was the head reader at a very prestigious publishing house, meaning she was giving notes and feedback to very famous authors, including four Nobel Prize laureates. You kind of have to know what you are doing when you are sending a manuscript full of red in the margins and the person can respond “I’ve got a Nobel Prize and you don’t.” She definitely had the icey stare to match.
Oddly, her advice was incredibly simple, and fitted in two very short pieces:
* Subject, Verb, Complement –– in that order. If you see two verbs, but a period between them.
* Things are confusing if you don’t put them in order: start by the beginning, find the widest piece of context that explain the rest.
I don’t apply her rules every time, but for every technical document, every time I’ve tried, it’s been night and day.
That typographic argument is really resonating with me.
Sounds interesting. Can you explain this?
> I asked the person who was standing there.
It has even more oratory precautions:
> We can argue that this result, that was seemingly proven wrong by a previous analysis, appear to be a consequence of a previous attempt that was investigated by my esteemed colleagues, who have looked into the author and found out that they …
If you want to split between each verb as they are, you end up with sentences that are in the wrong order:
> I asked a person. That person was standing there.
> We can argue that this result appear to be a consequence of a previous attempt. This result was seemingly proven wrong by a previous analysis. The attempt was investigated by my esteemed colleagues. My colleagues have looked into the author. They found out that the author…
So you are better off by thinking: what comes first? The person was standing there _before_ I asked, and I asked them because they were standing, so that information should come first:
> A person was standing there. I asked them.
Further, most actions in a chain of preposition explain a decision: those should come first.
> This result was surprising. Sceptics wanted to verify it. Their investigation concluded that the result was wrong. My colleagues wanted to know more. They investigated the authors of the result. They found out…
The outcome is a bit drier. The benefit is that if one sentence is longer, or an adjective inverted, or a complement put at the begining of the sentence, it’s more striking. That helps attracting attention to what matters, selectively.
For academic writing, you don’t need as many oratory precautions because you can report other findings without having to validate them as yours: you present them all as facts on equal footing. If you agree, it’s implied from the lack of criticism. If you disagree, it’s on you to prove why _after_ presenting the work fairly. For that, you have to include the key aspect to support you criticism in your first presentation.
I can also give the impression that you are just moving forward without a clear goal: “This happened, in particular then this happened, then this reacted…” which is why you want to summarise your point early: people will see the arguement getting closer to its goal, knowing what that goal is.
You can tell they don't read them because they ask questions that were answered in them.
/s
Because that tends to be how people skim.
If the first sentence of a paragraph doesn't catch their attention in some way, they subconsciously assume that the rest of the paragraph (which is presumably related) doesn't need to be read.
Also please rehearse what you would say to your family if you got into a car wreck and they wanted to check you out at the hospital versus “mom is going into surgery for massive hemorrhaging.”
“Hey son, we’re okay, but we got into a bad fender bender and we’re getting checked out at Hoskin’s Hospital. The car is dead so can you come pick us up, maybe bring X and Y and have your sister check on the cats?”
Is a way shorter moment of sheer terror than switching around the sentence fragments at the beginning. Also if you’re a boss having an unscheduled meeting with someone, stalling the agenda is just torturing the other person.
Help people triage. Make the urgency clear in the first couple words. Don't just send "hi" and then wait for a response, nor "X is down" when someone else is already on it and you're just giving them an FYI.
> Not publishing one sentence per line, no. Write like this for your eyes only. HTML or Markdown combine separate lines into one paragraph.
The military expression is BLUF - Bottom Line Up Front. (It works for paragraphs as well as for entire documents.)
Now listen. I vary the sentence length, and I create music. Music. The writing sings. It has a pleasant rhythm, a lilt, a harmony. I use short sentences. And I use sentences of medium length. And sometimes, when I am certain the reader is rested, I will engage him with a sentence of considerable length, a sentence that burns with energy and builds with all the impetus of a crescendo, the roll of the drums, the crash of the cymbals–sounds that say listen to this, it is important.
So I write with a combination of short, medium, and long sentences. Create a sound that pleases the reader’s ear. Don’t just write words. Write music.
(Gary Provost)
To be fair, and are we not all about being fair around here, he explicitly states:
> Not publishing one sentence per line, no. Write like this for your eyes only.
On the other hand, I find it hard to believe that there should be no spillage between how you write and how you publish. For example, I found "How to live" unreadable partly because of what I suspect this style of writing did to the published product.
with line breaks after grammatical units.
I've noticed that since I started doing so,
I've been writing longer paragraphs and sentences,
since the line breaks in the source do for me
what paragraph and sentence breaks do for the reader.
It's something I have to pay attention to.
Though if you wanted to get fancy you could use other vim movement commands (yank the next 2 sentences), I still think it's easier using lines.
EDIT: I just want to point that differently from this thread, the article is not about text style.
For technical writing, "no more than one thought per sentence" works quite well in my opinion. Or at least it's a good guideline to apply in the first pass of proofreading.
I guess what I'm trying to get across is not a single thought but a perspective which requires some background and context to appreciate, and I struggle with separating out the essential from the incidental, and structuring it for maximum engagement.
It is such a simple technique, that makes such a huge impact on ones writing, and yet no teacher bothered to teach it. I spent all my school years writing monotonous essays of five-word sentences. Week after week I would make another one, and I could clearly see for myself that they were bad, I just couldn't tell why. So when I asked my teachers for help, asking "what is wrong with my writing?", "what am I missing?", all I ever got back was a bad grade and the same useless tip: "just read more".
They might just as well have said to "draw the rest of the fucking owl."
There is generally no "hack" that the student can use to avoid having to read a lot of stuff, in order to learn and especially to become an expert. What a student needs to read, isn't necessarily textbooks or the traditional orthodoxy of materials, but still there is undoubtedly a lot of reading that must be done, to "get good" as they say.
That being said, for a teacher to GUIDE that reading, to give some hints, pointers, themes, interconnections, sequencing (start with X, then read Y to deepen your knowledge of X), etc., is absolutely invaluable.
To me, this seems like the Pareto-optimal 80/20 breakdown, where 20% of the teacher's investment in time and energy can get you 80% of the benefit of having teaching at all (i.e. don't need a full curriculum or full-time commitment to dedicated instruction, but do need to spend some time/energy pointing the student in various directions and giving them some ideas to think about while reading).
It’s useless advice to a student asking for specific help. A cooking student asking “why is my rice always soggy” should hear “let’s start by examining how much water you’re using”, not “watch more cooking shows until you understand through osmosis”.
The point of a teacher is to teach. If the only guidance they can muster is “consume more of what you’re trying to create”, there’s no point to having a class.
I've seen a lot of baseball and golf, and I still don't know how to even try to swing those things properly.
Reading more would be reading problems. Doing practice problems is equivalent to writing and having someone/something point out if it's good or not.
Many if not most modern writing advice will remind you to focus on your audience. Most audiences aren't composed of eight year olds. So it isn't true that most advice suggests writing for eight year olds.
> As a result, the level of reading and comprehension for most people has decreased to a level that is lower than in any other literate society.
We track statistics like reading comprehension and you can look them up. I did. The source I found showed that every state in the US I checked - with the exception of Michigan (??) - has reading comprehension improve relative to the year 2003. In some cases this improvement is by a notable amount, in some cases not so notable.
It seems unlikely to me that people now are worse at reading and writing than people used to be. Writing is more common now and reading is more common too. Once, journalists wrote. Now everyone does.
That may be true although I can tell you from personal experience that writing optimizers for places like trade press sites absolutely push you towards more basic language, shorter sentences, etc. One site in particular I used to write for sometimes told me every single time that I should basically dumb down my prose. And I don't write in a particularly literary way and I've pretty much never had this feedback from human editors.
>Once, journalists wrote. Now everyone does.
Interesting observation. At one point, most business people above a certain level were "writing" by dictating to their secretaries which is a completely different mode of getting information onto a page.
It does exist. It can be as harmful as you think it is. Yet it isn't harmful everywhere - isn't the world at large without any variation. It is intimately tied to the environment you are in, because that environment produces the rewards. Different environment, different reward, different impact on your writing. The effect is local, not global.
Which means you get to have a superpower.
When you have a bad transformation that degrades thinking that makes the term "medium is the message" feel dangerous. So you get things like Neil Postman's Amusing Ourselves to Death. I think your post is an example of the same type of fear. This focus - on the examples of times where things are negative - it misses the opportunity. Since messages are a function not of raw ideas, but of their audiences you have an incredible power. Choose the right audience. Set the expectation for evaluation in advance. Pick the medium that helps you to think clearly and makes it easy to be judged. Now, instead of being destroyed by your incentive environment, you get empowered by it.
Take a look at Amazon's writing culture for an example of that. Or more broadly, the many companies which chose to ban powerpoint for reasons which are fundamentally related to what I'm talking about. We're not worse at understanding writing than ever before. We're more advanced than ever before, because we stand atop the giants that came before us. Yet at the same time - we're not, because that too is local and not global. The future is often already here, but isn't evenly distributed.
Would it be possible for you share an example of your prose that received this criticism?
https://www.techtarget.com/contributor/Gordon-Haff
And that's probably after I made a few token changes to make the plug-in happier.
As in: practice makes perfect. Observing a master, will make you a master.
But unless your eye or brain can detect what they're doing, it can feel hopeless.
Sometimes having it broken out like this really helps. I found this amazing too!
So really, perfect practice makes perfect. Or at least saves time and avoids forming bad habits along the way.
I thought it was a useful point because I write with one line per sentence, but had only considered the first advantage.
Quotes: https://www.goodreads.com/work/quotes/50666270-days-without-...
The criminally unknown Janni Howker borders on poetry in her prose. Try Martin Farrell.
A professor at college tried to hone into us the short-precise nature of English as a cultural phenomenon and considered the paragraph long highly artistic German texts a reflection of a culture that felt the need to impress.
Still to this day, I admire both: the sophisticated elaborate construction of long flowery sentences that strain your memory as well as the ultra-concise that brilliantly clear short (often technical) prose.
What is this obsession with writing not being boring? If you're reading the passphrase to disarm a nuclear missile do you think you might get bored halfway if the sentences are too long?
I never understood why people insist on having short sentences. Human thought does not come in a small pre-packaged short sentence form. Some of the best philosophers wrote very long sentences, look at Nietzsche, Schopenhauer, Kant. Let's not dumb ourselves down by sacrificing rich, deep thoughts just because our ADHD might kick in and we might get distracted by the next YouTube cat video.
This may come as a surprise, but sometimes a piece of writing is not technical documentation.
> But several together become monotonous.
I was delighted when I first read the short, punchy, and somewhat dislocated clauses of The Stranger by Camus. Actually, a more pertinent example is the first page or so of Molloy by Samuel Beckett. Maybe the reader is supposed to be bored; I find it refreshing.
So, I've build myself an app to make that easier. Essentially, it's just a more stupid version of a text box. It's free, it's private, and it's meant to put you in the state of flow.
I've been using it every day for the past 3 years or so and I know that some people find it useful too, but even if I was the only user, I'd still be quite happy with it, since I suck at sticking with habits :)
Check it out!
I think there's still potential in writing tools with decent UX (iA Writer and such) and I know that some people wanted to pay me for Enso, so I'm trying to figure out the best course of action: either charge premium for a premium native app or let the people chip in. Paid products tend to get more valuable feedback.
You've (re)discovered the old adage: write drunk, edit sober.
"[...] to say istead of how you want to say it."
Instead is missing a "n". :)
Content: i’m currently on my mobile phone and I absolutely adore the idea of Enso (funny enough I’m currently holding & feeding my infant named Enzo). I would like to write with it and try it when I don’t have an infant on my lap but that requires me remembering it and looking it up when back on my laptop and ready to write something.
I added my email on the mobile sign-up but frankly I don’t really want a mobile app as 60% of my long-form mobile writing is done via voice to text and edited later. What I’d like is a “remind me via email to give Enso a try” signup that says “hey, this is a reminder to try Enso… The flow focused, low editing app for creative writing” or something like that.
I like this. Thanks! Email notifications nowadays are a bit of a pain to set up, since they need to contain the physical address of the sender in the footer, so this is a piece of work I _always_ keep postponing. I was even considering dropping that form completely. Maybe I could generate a calendar event with a reminder instead? This way I won't have to store any data about the user and I could probably piggy back on the phone UX when it comes to reminders. Just thinking aloud here.
> as 60% of my long-form mobile writing is done via voice to text and edited later.
Yeah, your description matches my own usage patterns. And, I've reached a similar conclusion. Mobile-first Ensō would probably have two modes: keyboard + dictation.
The sequenced auto responders that they have boost my open and click rates as much as 300% and allow for some truly powerful/complex programmatic features that anyone who's on HN would love.
Cheers, will give it a shot! (or just get the damn PO Box)
You could also just send yourself an email, you know.
Or, if you're fancy, use a to-do list that you can access both on your mobile and your computer.
(To be fair, I recall the brain-fog that comes with having an infant.)
So, yes, I could use a Todo list or some other solution to remind myself. But that inherently assumes this rises to the level of neurally important... which trying out a new tool rarely is.
That's why I offered a marketing/growth idea to better help passers-by remember to try it out in a super clean UX way that integrates with their workflow.
Strange there is no truly "semantic" way to mark-up sub-paragraph chunk of text in HTML; all 'inline' tags are intended for "words" or for including several sentences at once (like emphasis, quote, code, sample, mark, etc.). I have some murky memory I've read some discussion explaining that the concept of "sentence" is quite problematic and in no way universal, but cannot dig it up now.
(This comment started as But how are we supposed to sneak our beloved double spaces between sentences in the output now? semi-pun, but after all, this post-processing idea answers it.)
https://news.ycombinator.com/item?id=31695393
https://rhodesmill.org/brandon/2012/one-sentence-per-line/
https://news.ycombinator.com/item?id=4642395
http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-...
But the OP is saying that it's useful to make the sausage that way, not sell it that way, which is a different point.
Uh oh, that’s incompatible with standard em dash usage, which is with no surrounding whitespace.
(I’m designing a lightweight markup language of my own, and it’s tempting to special-case an em dash at the end of a line that is not preceded by a space, to join to the next line without inserting a space, but I’ve been trying to avoid nuance in rules. But I definitely do want to put line breaks after em dashes sometimes.)
Though I prefer the spaced en dash myself, and I am in the UK, I think there's probably a lot of variation on both sides of the Atlantic.
-->like this. I'm okay with that because there are some edge cases [1] in CommonMark that I absolutely need to use one anyway.
[1] https://talk.commonmark.org/t/foo-works-but-foo-fails/2528
But in that case I would prefer that the source text still has no spaces. Such things can be added in postprocessing.
> 3. A semantic line break SHOULD NOT alter the intended meaning of the text.
That should be #1 MUST NOT
Adding a semantic line break inherently changes the relationship between words, and we can't always be sure about the intended meaning of text. If this were MUST NOT, then any modification would risk violating the spec.
Then again, this may be my own, idiosyncratic reading of RFC 2119. If you'd like to discuss this further, feel free to open an issue on the GitHub repo here: https://github.com/sembr/specification/issues
Either way, though, for sentence source formatting, sentences on line boundaries also help version control systems since a diff shows the delta on a per sentence basis. Note that this is slightly different than one per line - it is more integer number of lines per sentence since some are multi-line. Same ethos, though.
They used to translate my emails, "in-place," so this allowed the translators to insert a line of Kanji characters, below each of my lines.
It also taught me to be frugal in my content, but you'd never know it, reading my stuff, these days...
Write the exact same paragraph, one with an EOL between each sentence, one without.
Natives always understood the paragraph with EOL. Personally I didn't see any difference but ¯\_(ツ)_/¯
I think it's true all the time, but it shows a lot more when you speak in a language where the grammar is super different from what you're used too.
It's more like "One sentence per page(s) — https://nathanbrixius.wordpress.com/2013/10/30/the-five-long...
A) He says in the SOURCE not the published, in literally the third paragraph. B) Count the damned sentences in the first handful of paragraphs. 2,3,3,1,4. He's clearly not saying you should do the stupid one paragraph per sentence nonsense in the published article.
This is a great idea for those of us who like writing prose in vim. Will adopt!
;; one sentence per line (defun wrap-at-sentences () "Fills the current paragraph, but starts each sentence on a new line." (interactive) (save-excursion ;; Select the entire paragraph. (mark-paragraph) ;; Move to the start of the paragraph. (goto-char (region-beginning)) ;; Record the location of the end of the paragraph. (setq end-of-paragraph (region-end)) ;; Wrap lines with 'hard' newlines (i.e., real line breaks). (let ((use-hard-newlines 't)) ;; Loop over each sentence in the paragraph. (while (< (point) end-of-paragraph) ;; Determine the region spanned by the sentence. (setq start-of-sentence (point)) (forward-sentence) ;; Wrap the sentence with hard newlines. (fill-region start-of-sentence (point)) ;; Delete the whitespace following the period, if any. (while (char-equal (char-syntax (preceding-char)) ?\s) (delete-char -1)) ;; Insert a newline before the next sentence. (insert "\n")))))
(global-set-key (kbd "M-j") 'wrap-at-sentences)
You need to have a empty line between each line on HN for it to format correctly. If you also ident it by four space, it gets marked as code in the markup.
;; one sentence per line
(defun wrap-at-sentences ()
"Fills the current paragraph, but starts each sentence on a new line."
(interactive)
(save-excursion
;; Select the entire paragraph.
(mark-paragraph)
;; Move to the start of the paragraph.
(goto-char (region-beginning))
;; Record the location of the end of the paragraph.
(setq end-of-paragraph (region-end))
;; Wrap lines with 'hard' newlines (i.e., real line breaks).
(let ((use-hard-newlines 't))
;; Loop over each sentence in the paragraph.
(while (< (point) end-of-paragraph)
;; Determine the region spanned by the sentence.
(setq start-of-sentence (point))
(forward-sentence)
;; Wrap the sentence with hard newlines.
(fill-region start-of-sentence (point))
;; Delete the whitespace following the period, if any.
(while (char-equal (char-syntax (preceding-char)) ?\s)
(delete-char -1))
;; Insert a newline before the next sentence.
(insert "\n")))))
I think the idea is that, if your sentence can stand up to the added scrutiny you'll give it while seeing it sitting all alone, then it is worth keeping. Otherwise it is a wasteful sentence.
Anyway, I do agree that the actual "one sentence per line" prose that is so pervasive on places like LinkedIn is awful.
Paragraphs — like punctuation, grammar, syncopation, etc. etc. — express semantic intent. They're not, like, type faces. They're one of the tools that ·authors· use to communicate meaning.
The first thing that stood out to me was the robotic nature of his writing. It seems like he's going so far out of his way to remove "unnecessary" words from sentences, and remove "unnecessary" sentences from his paragraphs, and to stringently vary his sentence lengths, that he winds up writing unnatural language. If you write in a way people aren't accustomed to, your readers are going to have a harder time understanding you.
"Sometimes short. Sometimes long." "Cut three lines. Paste them up above."
This isn't how English is used.
> be me
> write one sentence per line
> looks like greentext
> mfw
> Limit each paragraph to a single message. A single sentence can be a paragraph. [...] > Keep sentences short, simply constructed and direct. [...]
Most times when loads of people are "doing it wrong" then it's the technology that is at fault, and not the people.
On Android, I could filter out which apps could notify the watch, on ios, it seems Garmin has not been able to do that.
It isn't the main point of https://github.com/neilbrown/wiggle , but it can actually diff and merge on a word basis. A git merge driver is fairly easy to set up.
You might not have ever realized this fact because the character length of a typical line is so short, both in a columnar newspaper and on an ad-ridden website.
This is a tool that allows for applying simple regular expression based rules to enforce style rules. The idea is that you can tune this to your needs and cover all sorts of stylistic rules. For example, gender neutrality might be a desirable thing in the documentation for some tech companies and you can get it to flag things that are clearly not gender neutral.
Another thing worth mentioning is Jetbrains Grazie Professional (warning it's different from the normal grazie plugin, which is confusing), which actually integrates vale and can be used as a plugin for editing both code comments and markdown files in Intellij and other Jetbrains IDEs.
In general, treating text like you would treat programming code as a thing that has rules that can be figured out and enforced is a good mindset. I learned to write coherent text while doing my Ph. D. a long time ago. At some point I figured out that anything I'm doing consistently wrong, I can just learn to do consistently right. I just need to be open for criticism and figure out why something is wrong/not ideal. You kind of learn to look for things that you've done wrong before in your own text and then you fix it. A lot of these rules aren't rocket science. You just need to know about them. There's a whole grey area between grammatically correct and stylistically pleasing/acceptable. Having tools point out things that are likely problematic helps.
I just continue writing down thoughts as they occur, any time they happen during the day or during periods of concentration on the piece itself. If the current thought is not an extension of the last thing I wrote, I make a new line and start the new thought.
Here's a small section of draft notes for a technical article that I never published:
Streaming only for top level args, not deeply nested.... ?
- With set of files, need lots of streams of data.
-- How to get metadata when ordering not guaranteed?
------------------------------------
Is there a way to evaluate, send data from smallest piece to biggest piece?
- Walk the tree, assign weights to branches?
If a hierarchy contains multiple big data pieces, how to tell the receiving function?
Some method to pump in top level args X items at a time?
- 1 item at a time for non-array, x bytes at a time for array
-----------------------------------
Eventually, the summary notes start to feel solid in my mind, at which point I turn them into prose and then start embedding my notes between the paragraphs, turning them into sentences only once I feel I know where they should go in the overall piece. Once the notes finally disappear from the prose, I have my first draft.
I am looking for resources on the technical aspects of creative writing. Like this post. Or as mentioned below, on using semantic line breaks https://sembr.org/
I am trying to improve my creative writing style but most what I find on Google is about the creative aspect and not about the technical aspect.
Though I suspect that the motivation is different.
I don't think that's the word you're looking for =)
(Since we're on the topic of words in this thread.)
Edit: Oh come now... Editing your post to also say what I replied, then voting me down is poor sportsmanship old chap.
This is a paragraph with no linebreaks.
This is a paragraph with
one linebreak but without trailing spaces
This is a paragraph with one
line break and trailing spaces on previous line
Here is a demo of it in action: https://jbt.github.io/markdown-editor/#dY3RCYAwDET/M8VN4DQuE...
The problem with it is that it's so "invisible" and that some editors/people have things setup to strip trailing whitespace by default.
I wish there was a simpler way, like "@ at the end of a line indicates a hard line break", but at well.
[0] https://www.amazon.com/10-Solution-Ken-Rand-ebook/dp/B07FC7G...
[1] https://www.washingtonpost.com/local/bill-walsh-copy-editor-...
Who is the judge of 'it improved my writing more than anything else'? What was the 'anything else' for that matter.
This is a particular writing style just like Aaron Sorkin has a particular style. Some people like that style to others it's annoying.
https://thescriptlab.com/features/10569-5-secrets-to-aaron-s...
> We sometimes write sentences that don’t need to exist. Hidden in a paragraph, we might not notice. Standing on their own, we notice. Delete any sentence not worthy of its own line.
If you proofread and review what you write why would you not notice?
> Who is the judge of 'it improved my writing more than anything else'?
Who do you think? Who wrote the article? The word 'my' might be a hint.
> What was the 'anything else' for that matter.
Would you give him permission to describe one practice he adopted while writing without describing every single step he's made in learning how to write since he was a child?
I am challenging how someone arrives at that conclusion if they are the judge (which seems implied). Sivers gives nothing at all to indicate - not even anecdotes - as backup for the improvement. His statement is general and broad.
Let's say he was instead describing writing he did for school or for work. So before he applied his technique he was rated or judged a certain way (grades, reviews). Then he started to use the technique he describes. He then gets better grades or reviews. In that case he concludes 'it improved my writing more than anything else' (and I might still ask 'what are the other things you tried that did not work'. But in this case all he says (again) is a very broad and not in any way backed up 'it improved my writing'. And he claims 'advice to anyone who writes' he can't be serious using 'anyone' in that 'polished' sentence other than to get people worked up over a blog post and talking about it (which to be clear is a technique that bloggers use)
> Would you give him permission to describe one practice he adopted while writing without describing every single step he's made in learning how to write since he was a child?
People read what others have written and critique. My guess is that if he read my comment he might think that someone thought a certain thing and wonder and then maybe he would learn and/or make an adjustment. Not the reason I made my comment but there is nothing that indicates he should not be criticized or that others can't learn from the statements that I made whether they agree or not with what I said.
> It's suggesting that you write one sentence per line, polish the individual sentences
Again he is not even indicating when his technique matters. I write every day (for sales) I get very good results (judged by replies and results). In my case I don't have to polish every sentence I write enough and have enough feedback that I find that sometimes you don't even want to care that much because that in itself (in certain situations) telegraphs something.
You don't think starting a post with this is a bit to broad:
"My advice to anyone who writes: Try writing one sentence per line."
Seems very clear to me 'advice to anyone who writes' seriously 'anyone'?
When I sit down and try and write the “perfect paragraph”, I get paralyzed. But if I just start barfing out semi-coherent thoughts line by line, I find I’m able to get unblocked, then I can come back and edit.
Here is what the previous paragraph would look like in her style:
The mathematician Lillian R. Lieber
wrote a number of expository books
in which the text had one phrase per line.
I found this extremely easy to read,
and I write my LaTex this way,
which makes it very easy to edit.
I highly recommend the wikipedia article about her and its references:
https://en.wikipedia.org/wiki/Lillian_Rosanoff_Lieber#Unusua...
I get intimidated when I see big blocks of text.
But take that same, intimidating block and thoughtfully break it into short, punchier paragraphs and I'm in.
Shorter paragraphs make it easier for me to skim and get a sense of where something is going. They also give me more chances to pause, catch my breath, and internalize what I'm reading.
This is harder for me to do in a big block of text where I'm afraid I'll lose my place if I divert my attention.
I‘ll try switching from line wrap to full display to get a better picture of the overall structure.
If the structure is easy to recognize I would probably prefer a simple model that tells me a good line length for the current line I‘m in, e.g. a simple writing plugin for the editor of choice.
As a German speaker, I feel like English prose is already extremely biased towards short sentences. This makes some sense, as German has much more grammar to make these sentences readable and unambiguous.
At some point, I feel like making sentences even shorter does not aid the readability, but rather stands in its way.
Not necessarily the containment of each sentence to a single line, but a new line between each sentence to maintain separation.
However, I can also agree that this style might be not suitable for non-technical writing.
I wish I had done this while writing my PhD thesis.
"Omit needless words."
-William Strunk, The Elements of Style
Highly recommended book for anyone who wants to be a more effective writer.
> The book's toxic mix of purism, atavism, and personal eccentricity is not underpinned by a proper grounding in English grammar. It is often so misguided that the authors appear not to notice their own egregious flouting of its own rules ... It's sad. Several generations of college students learned their grammar from the uninformed bossiness of Strunk and White, and the result is a nation of educated people who know they feel vaguely anxious and insecure whenever they write however or than me or was or which, but can't tell you why.
(See also "50 Years of Stupid Grammar Advice" at, eg, https://www.cambridge.org/core/services/aop-file-manager/fil... . Language Log recommends https://www.google.com/search?hl=en&q=Strunk+site%3Ahttp%3A%... as a way to find further criticism from them.)
For "Omit needless words", a problem is identifying what "needless" means. Quoting http://itre.cis.upenn.edu/~myl/languagelog/archives/004552.h...:
> Whenever you see an appeal to ONW, you should wonder what people are doing with those "needless" words. Most of the time, those extra words are serving some function that conflicts with brevity; they're doing some work.
There are also examples how that phrase (likely) caused people to believe that if a word can be omitted then in must be ommitted, like http://itre.cis.upenn.edu/~myl/languagelog/archives/004176.h... and http://itre.cis.upenn.edu/~myl/languagelog/archives/000994.h... .
Or how in White's own writings he "sometimes throws in a few extra words just for the sheer resonant fun of it" - http://itre.cis.upenn.edu/~myl/languagelog/archives/001904.h... .
FWIW, I think "don't be too wordy" is more accurate and less likely to be misunderstood than "omit needless words", and one character shorter.
(Personally, I still recall my utter confusion in 11th grade English trying to figure what "passive" meant when told to avoid it. Turns out three of the four examples of passive in "The Elements of Style" ... aren't passive! And yes, I got marked off for using what may- or may-not have been the passive.)
Unless, of course, you're taking a class, in which case the rules are whatever the professor says they are. There's a reason academic writing isn't often very enjoyable to read.
I don't understand the relevance of "academic writing" as 1) Strunk and White is widely recommended to authors in general, 2) 10+ million copies sold aren't mostly going to academia, and 3) examples from the book show a bias against what Wikipedia at https://en.wikipedia.org/wiki/Academic_writing characterizes as "academic writing".
Eg, "The Elements of Style" really does not like the noncommittal academic writing style of the following (quoting from https://archive.org/details/elementsofstylew00stru/page/14/m... ):
> The Taming of the Shrew is rather weak in spots. Shakespeare does not portray Katharine as a very admirable character, nor doe Bianca remain long in memory as an important character in Shakespear's works.
and instead prefers:
> The women in The Taming of the Shrew are unattractive. Katharine is disagreeable, Bianca insignificant.
Strunk and White’s disarming treatment of what everybody really needs to know about writing has been treasured by generations of people who are occasionally forced to write something and view the prospect with a sinking feeling of dread. As a guide to writing, The Elements of Style, being little more than an apparently arbitrary mixture of grammatical digest, handy list of common mistakes, and expert hand-holding, is drastically incomplete, but it is a masterpiece of psychological insight. Its attractions derive, we suspect, first, from its implicit, cheery, and optimistic promise that if you just read its few pages and work those few surface tricks it teaches you (“In summaries, keep to one tense,” “less should not be used for fewer”), you will not embarrass yourself; second, from its exhortatory cheerleading that seems so assured and upbeat; and third, from its tone of common sense that masks, at key points, an essential vacuousness: “Choose a suitable design and hold to it.”
Edit: oh and by the way, the two authors recommend this as a better alternative (I haven't read it): Style: Toward Clarity and Grace, by Joseph Williams and Gregory Colomb
Many news outlets now use this as standard for publishing.
Random example: every article at https://www.abc.net.au/
I challenge you to find a (non-quote) paragraph with more than one sentence!
(Incidentally, it is not too hard to find multi-sentence paragraphs in news stories, though it is rare to find anything exceeding three sentences.)
For years I didn’t even consider there was an alternive to writing in paragraphs, despite using git and markdown daily.
And this is on line 4.
(And part of why I think the essay-as-tweet thread is so popular.)
Good advice though ;)
In the sum of the parts, there are only the parts.
The world must be measured by eye.”
- Wallace Stevens
There are many like it, but this one is mine.
His son recently released Essay, a tool to help write better, in the sense mentioned above.
His process is outlined here: https://medium.com/practicecomesfirst/dr-jordan-b-petersons-...
I believe the app is a tool to help you learn, practice, and internalize that process.
I love it.
This could change everything.
Future historians may thank us.
Seriously.
Thoughts?
- Ask for what I want/why did I sent this email.
- Explanation why using logical breaks.
Which usually means I write my email, take the last line and make it first.
If I'm emailing a technical colleague I'll include more details. CEO, 1 line bullet points.
That's not to say it's a bad technique. It might work for some, not for others. For me it doesn't.
I have found writing to be much like coding where if you think through the idea properly, writing to the end is not such a big problem. The main hurdles is getting stuck which is often an indicator of a poorly thoughtout idea.
The other thing that helps me escape the over-editting issue is putting my words down with as much brevity is possible. The more fluff there is, the harder it is to change. Simpler to read, simpler to edit.
> Not publishing one sentence per line, no. Write like this for your eyes only.
(Edit: added quote from article)