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.
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.
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.
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.
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.
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.
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)
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.
I personally use this approach but mostly because a lot of what I write ends up in a git repository and diffs make way more sense when there is only one sentence per line. I also find things much easier to manipulate in vim when sentences don't span lines.
> diffs make way more sense when there is only one sentence per line
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.
There is! If you're using Git, you can do git diff --word-diff to enable word mode, which is computationally more expensive, but computing power is cheap these days. There's also an "ignore whitespace" mode (-w), though that doesn't play well with Python.
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.
You could write a script which replaces the end of sentences with a new line and use git hooks[0] to run it before every commit. You wouldn't have to write any differently.
That's about as unnatural for most people as newline per sentence, and has the added risk that you'll accidentally publish like that and it'll look weird. One per line would be _much_ harder to accidentally publish because it's more obvious.
Two spaces between sentences is how I've always typed them, even if it's in HTML or MD or other forms that will condense them into a single space in the final render. The two spaces mark a clear intent to end a sentence instead of a period to punctuate an abbreviation.
Many people learned to add two spaces to the end of each sentence which is now built in to their muscle memory. My father learned to type adding two spaces to the end of every sentence, they tried to teach that to me in computer class in middle school but since I had a lot of experience typing already without it I never felt motivated to change my habit to add two spaces. I never really saw the point, in most formats I can't see the two spaces.
Two spaces after each sentence comes from typewriters, where it supposedly looked better. On computers it made sense in the time of monospaced fonts, but with "modern" fonts being able to control the amount of space behind punctuation it's largely redundant.
For me it's a holdover from a high school typing class, but I find it useful. I mostly write in LaTeX which just ignores the extras. On the iphone, two spaces are replaced by a period and a space, which is quite handy.
Good typography seems to dictate a wider space after a sentence than between words. So this is a typewriter habit to mimic that kind of thing (like the sibling noted).
Rendering engines can do anything they want. The question is about source representation only, for semantic purposes. That has nothing to do with output representation. Even practicaltypography completely misses that distinction.
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?
The period also indicates the previous word was abbreviated, or can be used in an ellipsis, probably other situations that aren't top of mind right now.
> 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.
Your reply cited Butterick which doesn't distinguish the two issues. Every "authority" I've seen strongly admonish against the use of two spaces fails to make this distinction. Which is why I emphasized it.
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.
Take a ruler to some text that's traditionally typeset and you'll notice that the width of the whitespace after a sentence end is slightly wider than the space between words. That's either an em space or an en quad. Between-word spacing would be about 1/2 an en.
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]
Those authorities on "good typography" are wrong. They prioritize text looking pretty over text conveying information clearly and accurately, and the world is worse off because of it. Two spaces as the sentence delimiter is superior in every way that actually matters, and I will die on that hill.
Yeah I believe this is a generational thing. I learned double-space as well, but pretty sure not long after me they stopped teaching that, and I've totally stopped doing it.
Double spaces was the norm on (almost always monospaced font) typewriters [EDIT: in English]. I assume it lingered on computers until sometime in the 80s but was shifting especially once proportional fonts for written material (other than things like code of course) became the norm.
I was taught to use double spaces in highschool typing class (we used electric typewriters with the buffer off). In the ~35 years since I have only ever met a handful of people, all older than me, who did it in practice.
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?
Apparently you could set up one or two spaces depending on your preference, however recent versions of Word now mark double spaces as an error by default.
I am an oldster, but never used two spaces. Probably because I never did typing lessons at school (hell I don't think it was even an option at my schools - computers hardly featured either).
Fair point, but I still prefer the solution of just putting in a new line myself. Then I don't have to worry about maintaining such a script, setting up the git hook, etc.
Yes, but I still find it more convenient to have sentences on their own line. Vim's sentence text object does also not always correspond correctly to actual sentences.
I mean, I’m happy that this was not a yet another sysadmin/programmer-as-writer justification (adjusting one’s whole workflow based on the handful of terminal programs that one uses).
EDIT: Meaning that I think this kind of justification is more interesting since it is meant to affect the process of writing itself.
I won't say I'm not guilty of that too sometimes. Although I don't think it's so bad. If there's a tool that you really like using that can be adapted to work in a variety of scenarios, I can understand the justification. For some of the things I do, there probably are better tools for the job, but if I can make use of existing tools I already know how to use well, even if in a suboptimal way, that might be more worthwhile to me than investing in learning something new.
Yeah, same here. If you're going to have any text commited to git, it'll work much better if it's one sentence per line. Not that git is great for prose, but it kinda does the job and I don't need to have a new tool. Hammers, nails.
> Not that git is great for prose, but it kinda does the job and I don't need to have a new tool.
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?
At least with a controlled circle of people who respect that, say, handing off a doc to an editor means they shouldn't make inline changes any longer, collaborative doc editing like Google Docs.
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).
I remember struggling to write essays when I was in highschool. Well, I was fine, but my teachers insisted it was long-winded gibberish. Concerned, my grand’mother told me: “Ask Sonia” I knew she was her friend, and they liked to argue a lot, but I was a bit confused by the advice.
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.
French, especially academic writing, can have a lot of subordinate clauses:
> 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.
I have to do this in my emails. Most people just ignore the second and third sentences in a paragraph. No idea why, drives me crazy - but this does help.
You can tell they don't read them because they ask questions that were answered in them.
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.
Which is why “don’t bury the lede” is such important advice.
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.
This is all also useful advice for helping people deal with notifications for work. They might see "@xyz can help you with this..." and miss "... when they have time next week".
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.
This sentence has five words. Here are five more words. Five-word sentences are fine. But several together become monotonous. Listen to what is happening. The writing is getting boring. The sound of it drones. It’s like a stuck record. The ear demands some variety.
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.
Reading this makes me angry at all my school teachers for the subjects of [my-native-language] and writing.
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."
Reading more is the best way to learn though. Having good examples to imitate and build off of make writing clear, engaging prose much easier. When my math teachers told me "just do the practice problems", I also thought they were idiots, but they were actually right...
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.
Reading as a reader is kinda different than reading as a writer. Different mind states. As a reader I'm getting lost in a story, not picking up on writing styles and patterns. You're not wrong. Just need the caveat of reading with the intention (or partial intention) to pull yourself out of the story and check out the architecture.
Reading more is good, but what if the teacher had pointed out the sentence length and told the student to start reflecting on sentence length while reading?
Outside of classroom-style dedicated instruction, this really does seem to be the best form of learning, i.e. a semi-active/not-fully-passive approach.
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).
This is all brushing up against the central theme of "Zen and the Art of Motorcycle Maintenance", which approaches its core thesis by dissecting the process of teaching college students how to "write Quality".
This is a problem with most advice on English writing. They only teach you how to write as at a level that a 8 years old reader would understand. Most modern books, fiction or not, are written at a juvenile level, at the formal request of publishers. 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.
> they only teach you how to write as at a level that a 8 years old reader would understand.
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.
>So it isn't true that most advice suggests writing for eight year olds.
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.
I believe you.
Medium is the message is a term from media theory.
It refers to the idea that messages aren't in a vacuum, but are shaped by where they are transmitted.
Often that shape is a function of what the audience will find appealing.
You can tie this sort of thing to bellman equations to get a mathematical grip on the effect.
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.
I think you’re both making good points in this thread. I’m writing a non-fiction book in my spare time, and I’ve had to face the fact that my default get-words-on-the-page is extremely flowery.
Would it be possible for you share an example of your prose that received this criticism?
I remember reading this as a child (maybe in elementary school) and it affecting my writing. I have to admit, especially when writing something technical, forgetting about this and focusing on making small, easily-understandable sentences can help the reader. (even though it's more boring)
A paragraph with just one 50-word sentence doesn't have varied sentence length either ;)
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 agree with no more than one thought per sentence in general, though I have the opposite problem: it often takes me several paragraphs to get a single thought across. So the end result ends up being something like 0.1 thoughts per sentence.
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.
I struggle with this, too. I'm just very verbose. I try to keep this piece of advice about working to shorten a text in mind: it's done, not when there is nothing more to add, but when nothing more can be removed. (Saint-Exupery, I believe). It helps me a little bit.
Technical text has an excuse to be boring and repetitive. The content is king, clarity and lack of ambiguity are the next most important things, and style is just a fourth place contender.
EDIT: I just want to point that differently from this thread, the article is not about text style.
The most fascinating experience is trying to understand Schopenhauer in German and then reading the same paragraph in an English translation. It feels pre-digested or narrowed down to one possible interpretation.
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.
I'm gonna be honest, my mind got bored in the long sentence and completely skipped like half the words. I think I'm just too used to reading documentation and skipping 50% of the words so I can see how to do something quicker.
I had the same experience when my brain decided that I get the point of the sentence and where it was going. Perhaps if there was actual content in the sentence this wouldn’t have happened.
He is not saying short sentences are necessary, he is saying that each sentence stands out with a newline, which means they can be judged at an individual level.
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.
Writing like this works really well for vim and git as well. It makes it easy to delete/move/edit lines (eg with: d2j), and then in git the diffs are by default formatted nicely and contain only sentences.
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.
The semicolon is doing a lot of heavy lifting in that sentence. That makes your example 5-10-5 words instead of 5-5-5-5. Try using a period instead of semicolon and hear how it sounds.
What difference does it make? They are multiples of five. Are they okay to him? I doubt that is so. He dislikes chunks of five. He was not prescribing semicolons. That would still bother him.
I think you might be missing the forest for the trees, here. It's not about five-word sentences; it's about the repetition making the paragraph as a whole monotonous and robotic - something you demonstrated very well in this very comment.
The OP primed you to read it robotically. I'll admit my sentences seem somewhat contrived though.
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.
Yes, and the hyperlink for "vary the lengths of our sentences" in the linked-to essay goes to another essay, by the same author - https://sive.rs/book/WritingTools - which includes that Gary Provost "tour de force".
it makes no difference tbh how varied the sentence length is or other aesthetic factors. nothing is reliably been shown to make writing more successful.
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.
I approach this by separating writing from editing. Just keep writing, ignore the typos, self-censorship or formatting and keep moving.
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 :)
Sweet! If you don't mind sharing, did anyone donate through ko-fi?
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.
Here’s my biggest critique of Enso:
It’s not very easy to send myself a reminder when I’m back at my computer to use it.
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.
Go get convertkit. It's bloody awesome, cheap, and they even have an address of their own that you can use if you don’t wqnt to share your physical address.
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.
It's a user experience thing. Too often product designers (myself especially) think that a user should remember/do an action/etc. However, I believe most failures are design failures VS user errors and that a better designed system could/should strive to fix them.
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.
I made a colorscheme for vim that uses same color for font and background. Use it sometimes when I need to write long confusing thoughts. It's quite a nice experience, the sentences turn out to be similar to the way I would speak, but still with more thought and deepness.
Reading this makes me think it might be generally beneficial to finally convey the semantics of sentence boundaries to the resulting output as well, like some `<p><span>Sentence #1.</span> <span>Sentence #2.</span>` wrappers: it would introduce possibility (for author or user) to break it into lines again or apply any other styling, and might improve interaction (think: select single sentence), or some further processing or contextual styling (think "make all single-sentence paragraphs stand out".)
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.)
I tell founders not to write like this, at least for HN, and I edit their launch posts when they do (https://news.ycombinator.com/launches), because it reads like a sales letter.
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.
> 5. A semantic line break SHOULD occur after an independent clause as punctuated by a comma (,), semicolon (;), colon (:), or em dash (—).
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.)
According to Wikipedia: "Dashes have been cited as being treated differently in the US and the UK, with the former preferring the use of an em dash with no additional spacing and the latter preferring a spaced en dash."
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.
A hairline space between em-dashes can be quite visually pleasing (in American writing; British uses full spaces around en-dashes). Like what Medium does.
But in that case I would prefer that the source text still has no spaces. Such things can be added in postprocessing.
SemBr author here. I chose SHOULD NOT for this rule for a couple reasons: First, as an affordance for text with ambiguous or unknown meaning. Second, as a hedge against introducing new meaning unintentionally.
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
Most writing style rules are context-dependently apt. The quote by Disruptive_Dave of Gary Provost rings true for artistic writing. Sentence length limits are more helpful for technical writing like papers/documentation, with its many side-details - just as a complexity control.
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.
This was the rule in the 1980s when using nroff and it's a habit I developed when using any markup. It's good to know that it's been rediscovered again as newcomers mature in their tool use.
Am I the only one thinking this thread should be immortalized as the ultimate example of how poorly HN readers read things before shit-posting about articles? Sigh.
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 can paralyze your writing. It invites you to over-scrutinize each line and lose sight of the whole. It's a view that's better suited for analysis than synthesis. So it's better for editing than composing.
I had copied this Emacs macro just for doing that.
;; 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")))))
"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")))))
Ironically, this snippet seems to be a bit too much wrapped!
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 makes prose feel sanctimonious, even self-aggrandizing. I find this dude's writing un-readable for exactly this reason. All of his articles are like HTML versions of the Ducks Go Quack TED Talk [0]. I just roll my eyes.
I also find his writing very unnatural and hard to read. It makes me seriously doubt his method, which he claims he's been using for twenty years.
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."
In his defense, he is saying to write "one sentence per line" only _while_ you are writing/editing. He says this is "for your eyes only", and that you'll recombine into paragraphs afterwards.
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.
At this point, I think it's wasted breath to try to respond to the people who skim over articles without comprehension (or who don't appear to read the articles at all) and who instead just respond to the title.
I understand the difference between one line per sentence at the source level, and at the presentation layer. As far as I can tell, articles on sivers.org demonstrate both.
I think the advice is still useful for editing. Personally, I'd add the extra step of re-consolidating the sentences into paragraphs after going through this editing phase though. That said, I do a lot of technical writing and I often find paragraphs with fewer sentences are my better written paragraphs.
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.
Just please, for the love of god, don't do it in slack. Nothing annoys me more than a colleague writing a long slack message when I'm AFK, and having my watch buzz like an angry bee when they hit one carriage return (and send a new slack message) every 10 seconds.
You should really be angry at Slack and not your colleagues. There are loads of ways to prevent this like sending at most one alert per user per minute (if message is unread). It's not rocket science.
Most times when loads of people are "doing it wrong" then it's the technology that is at fault, and not the people.
Over the past year I’ve disabled all Slack notifications and the result is increased focus while I’m writing some code or an email. All the messages will be queued up regardless if I’m being notified (and disrupted) often. Perhaps give it a try!
Personally, I have mapped ’send’ to cmd+enter, to avoid accidentally sending too soon. Also, to make it behave similarly within a code block as without.
One of the problems with Slack/Discord desktop clients is that the message area (center column) tends to be far too wide on HD monitors (1200px+), making it difficult to read[1] anything that hasn't been manually line-wrapped.
Many comments have mentioned both the benefits to diffing, and various --word-diff options. Unfortunately word-merge tools are harder to find. You can of course use smudge/clean filters to unwrap and rewrap text, but those are quite fiddly to set up and fragile in practice.
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.
Most news articles are written one sentence per line.
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.
Good advice. There are a few nice tools out there to support technical writing. I think one of them was featured on HN a few days ago: vale.
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.
When I write for myself, it's all over the place. Mostly it's short phrases, unordered lists and the odd diagram, followed by lines of --- to separate thought arenas. All of these are fragments of ideas that I feel will probably be important to the finished piece. Usually about half of them actually are.
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
-----------------------------------
Every so often I'll draw another line and summarize everything in a way that succinctly discusses what I'm writing about in note form. Then I draw another line and start writing notes again.
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.
Slightly off topic, but a pet peeve of mine is how you don't get a real line break in markdown when you insert a newline. Sometime I want a line break without a vertical apace for a new paragraph, I can't be the only one here!
I know I can normally just add a br tag, but that looks nasty when you read it as plain text.
That depends on the markdown implementation (like so many features). But most of them implement "two trailing spaces on previous line force line-break" so you can (in most places) do something like this:
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
That will render correctly on GitHub and other places (meaning, when rendered, the first one has no line-breaks, the second one has no line-breaks but the third one does [select the full third example to see the trailing spaces])
The two spaces-is-linebreak thing is in the commonmark specification, and has been a Markdown feature from the first Gruber Perl script, so it should be pretty compatible.
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.
I read Ken Rand's "10% Solution"[0] in ~2001 on the recommendation of longtime Washington Post copy chief Bill Walsh, who died a few years ago[1]. I can't believe how much of its advice has stuck with me and how much it has helped me. Highly recommended for anyone who wants to optimize their writing.
> My advice to anyone who writes: Try writing one sentence per line. I’ve been doing it for twenty years, and it improved my writing more than anything else.
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.
> 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?
This isn't suggesting that the things that you publish be one sentence per line. It's suggesting that you write one sentence per line, polish the individual sentences (and question their right to exist at all) then edit them into paragraphs. You might have assumed this assume this by noticing the fact that the article has more than one sentence per line.
> 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?
> Who do you think? Who wrote the article? The word 'my' might be a hint.
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'?
I like a version of this technique the best for curing writer’s block.
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.
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.
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:
I started doing this mostly for cleaner commits in version control systems. After a while I also noticed it made the writing more concise. It's much easier to spot redundant "filler" sentences.
I think the spirit of this advice translates well to publishing style, too.
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 write one sentence per line as well, but use line wrapping to make it more readable during writing. Reading long sentences on a single line is unpleasant imho.
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.
This reads like it was written by a third-grader. Accessible? Maybe. Enjoyable? Not in my book.
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.
This is my primary objection to using 80 columns everywhere. Markdown specifically is a painful place to require it, but also latex and HTML. For source code, 80-col works out ok most of the time since "sentences" are relatively short, but even there I prefer to use more semantic line breaks when the style guide or formatting tool does not omit them.
I completely agree.
Using one line per sentence (and soemtime more lines when the sentence is longer)
makes it way easier to structure the text.
Markdown and are perfectly able to fit the text to the device you are reading on.
It also makes version control and diffs more usable.
However, I can also agree that this style might be not suitable for non-technical writing.
Elsewhere, https://sive.rs/book/ShortSentences, Sivers recommends "Several Short Sentences About Writing", which is a perspective on writing that I'd not seen before. A useful read if you want to practice his present advice.
This is not a bad idea. Any decent toolchain will support rendering as paragraphs, including LaTeX. Another advantage not stated is version control and diffs work much better. You do have to put up with long lines, but most editors support wrapping long lines for display purposes.
I wish I had done this while writing my PhD thesis.
Authors of the excellent "Clear and Simple as the Truth: Writing Classic Prose," Francis-Noël Thomas and Mark Turner, have this to say about Elements of Style:
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
Have you read any of the criticism of the book? Its Wikipedia entry quotes Pullum:
> 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.
> 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.
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.)
Sure, I wouldn't recommend anyone ever take any writing guide as some kind of scripture to be followed dogmatically. As with any art, there are no real rules, only guidelines.
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.
Then Strunk and White isn't a good initial reference as they are pretty dogmatic in their many rules. White referred to "the remembered sting of [Strunk's] kindly lash", and likened the rules to a sergeant "snapping orders to his platoon." How are readers supposed to understand those orders aren't real?
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".
> 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.
However, the intent is different. The author is suggesting a general purpose method to facilitate a more engaging writing style that can be used even if the product contains paragraphs of multiple sentences. News outlets use it to facilitate the conveying of information to the reader.
(Incidentally, it is not too hard to find multi-sentence paragraphs in news stories, though it is rare to find anything exceeding three sentences.)
Months ago I noticed that I was doing this because of a (bad?) coding habit. It meant that my writing was recognizable across multiple reddit and discussion board accounts I don't want to be associated with each other. I stopped Writing One Sentence per Line after that.
I write a lot of LaTeX and articles. I sort of do this, except that I also really want reasonable line lengths. Each sentence starts on its own line, but I also hard wrap at 80 characters. I have a completely different set of editing tidbits for writing equations.
I write this way in Asciidoc, with a single line break between sentences and two line breaks between paragraphs, since it automatically compiles into normal paragraphs when I generate PDFs or Word documents. It makes editing so much easier.
I absolutely love doing this. I often write in LaTeX, where new lines don’t effect the typeset output. It is so much easier to see git diffs, comment sentences out, move sentences, identify a sentence by its line number, etc. as well.
If what you're writing gets rendered as markdown (i.e. a readme on github), you can actually publish as one-sentence-per-line, because the markdown parser will make them into a paragraph for you.
If you've ever had LaTeX docs in version control, you'll quickly appreciate this approach as well, since VCS is much more sane when dealing with lines.
This is a good habit if you write LaTeX documents, particularly with collaborators. It's much easier to diff a file where each sentence has its own line!
this is actually really good advice. shorter paragraphs force you to be concise, and concise is really good in short-attention-span mediums like reddit or email.
My criticism is that nearly the whole page is the comment section. The article itself is very short--pasted into an editor, ~200 words excluding titles. Perhaps putting every sentence on its own line also inflates an author's sense of how long their article is.
This is how man pages are written, and in the long run it’s really convenient. I’m guessing that’s also why it recently become the rule for FreeBSD documentation, after migrating from DocBook to AsciiDoc.
For me context is very important. Separating out the sentences, although makes them stand on their own, often sounds discontinuous and jarring like a too long pause. Not to mention how awkward it looks on the page (if double spaced which I prefer).
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.
You might have missed a part of the article, where author says they write single line sentences as 'code', but both Markdown and HTML automatically turn concescutive sentences into paragraphs, unless you (using a blank line or <p>) explicitly end a paragraph.
> Not publishing one sentence per line, no. Write like this for your eyes only.
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.