I disagree with a lot of this. My perspective comes from reading papers in mathematics and physics, not computing, however.
Regarding "grandmothering": I agree with the criticism of the first example. Explaining basic points of the field in a vague way is obviously not helpful. The second example is not as compelling. The key point is that the "..." after "In recent years, the study of preconditioners for iterative methods for solving large linear systems of equations, arising from discretizations of stationary boundary value problems of mathematical physics, has become a major focus of numerical analysts and engineers" usually contains a string of citations. These citations serve to point the reader to the recent works mentioned in the sentence, which may not be readily accessible to someone who doesn't actively do research in that area but is otherwise knowledgeable about numerical computing.
In particular, the author reasons such introductions are bad because "the bulk of the paper is accessible only to those sufficiently expert in the field to know everything in the first two paragraphs of the introduction cold." But this is just wrong. There are plenty of math/physics papers where I can follow the arguments line-by-line, but I don't know the state of the art in the field or why the problem under consideration might be important. I don't think I am alone.
Regarding, "A table of contents in a paragraph": I think the author is partially correct. For short papers, it's perfectly fine to fold this part into the introduction (e.g. in the outline of the proof). But for longer works where the proof is decomposed into multiple lemmas and sub-lemmas, these can be very useful. If one writes the proof in a very clear and structured way, then maybe such "shotgun summaries" can be avoided. But this is not always possible.
Regarding conclusions that only repeat the introduction: I agree here.
I like the "grandmothering" practice. Subfields are becoming more and more specialized. As a practitioner and not a researcher, it is not uncommon for me to be unfamiliar with half of the terminology in a paper because it is different from how things are described in my subfield, but once I look it all up, the concepts are pretty clear (and often similar to things I already knew under different names). Having a couple sentences at the beginning to describe in plain english what the context of this paper is, helps me figure out whether it is applicable to what I'm looking for, and identifies the major keywords that I can use to find a primer to get up to speed to understanding the rest.
For those who are active researchers in the field, having to skim a couple sentences before getting to the meat of the paper isn't a big deal.
I agree with what you're saying about the introduction and I think a lot of this depends on the exact type of article you're writing for. I also think the other has some point on the intro text. I work in optical telecom and many papers start with "the exponential increase in data demands over the last decades..." literally everyone in our field knows this. You don't need to be that general in technical conference papers. However if you write for e.g. Nature, Science or another high impact journal, the sentence is important because outsiders don't necessarily know about this.
Regarding the conclusion, I disagree with you and the author at least for short (2-4 Page) conference contributions. The Committee members are reading ~50-100 papers and often they read the abstract, intro and conclusion in detail and look at the figures. Those things will get your paper accepted. Essentially you want to stake your claims explain why they are important and show that you actually did what you claim. That should be seen from those things alone. That often means it should be possible to understand the paper/results from the conclusion. This is not a novel with some great reveal. That said, don't just summarize your paper draw conclusions.
>> These citations serve to point the reader to the recent works mentioned in the sentence, which may not be readily accessible to someone who doesn't actively do research in that area but is otherwise knowledgeable about numerical computing.
CS papers typically have a "Related Work" section for this. I agree with the author that the Intorduction section should be used to introduce the work to a reader who will proably not read anything else.
Actually, to be honest, I hate structured writing and I hate that research papers are always written as if they were meant to be read by 5-year olds with ADHD, but I know that the way most people read most papers is to read the abstract, skim the Introduction, browse the graphs in the Experiments section and then check the Conclusions section to see if they missed anything. I'm guilty of that too. There are way too many papers and too little time to read them all carefully. So papers end up written to be skimmed rather than read.
Another practical point concerning grandmothering is journal editors. Journal editors are often not experts in the specific subfield of the paper and almost certainly won't read much further than the first 1-2 paragraphs. Thus, the first 1-2 paragraphs must, in addition to stating what the paper does, give sufficient context to convince a lazy editor that the topic is important enough to be the focus of a paper in their journal. In my experience, grandmothering is often trying to achieve this purpose.
I generally agree with you, with the addition that when I write a "table of contents in a paragraph," I try to always help the reader figure out what they can and cannot (or should not) skip. Sometimes people just want a rough idea of what something is about, and they shouldn't be made to read through the whole paper to figure that out for themselves.
Also, I can imagine that the "in recent years" part might be helpful to someone reading the paper thirty years after it was published, even if today anyone who can get value out of the paper knows that.
No, because it's hard to accurately represent the tree structure and interdependence of lemmas with a linear table of contents. (Sometimes – not always!)
But for really nasty proofs, I think a graphic description of the structure is best. Check out Figure 3 on page 29 of this paper: https://arxiv.org/abs/1108.2291.
I agree these are annoying patterns, but I honestly don’t notice them. I don’t read research papers like a book, front to back. Often I skip the abstract, skim the intro, skip to the conclusion to skim what they say I’ll find, and then read the core. The table of contents paragraph I skip without thinking about it.
I’m more bothered by people who use bizarre notation, don’t provide sufficient definitions/background, and don’t give enough information to reproduce the results myself (and I’m not talking about a git repo). I could care less if they have useless sentences and repetition if the content and methodology is complete and understandable.
> I agree these are annoying patterns, but I honestly don’t notice them. I don’t read research papers like a book, front to back.
I think you've hit the nail on the head. The articles "sins" don't matter because experts skip over these parts. And this is the reason they are not a focus of the authors.
I still think the article points out things that can be improved but the benefit is taking a good paper and making it more palatable to people who are not experts or on-the-way to being experts, thus expanding the population of people who might cite the paper.
> The articles "sins" don't matter because experts skip over these parts.
Yes and no. Yes in the sense that if you are an expert trying to stay current in your field, you will skip around a lot in most papers.
But no in the sense that when you find a paper that is especially relevant to what you are doing, you will read and scrutinize every single word, symbol, and figure in that paper until it’s completely mined of all relevant information.
I think one reason the intro isn’t always a huge focus is because it’s literally written last in many cases. There are typically page limits, or a cost per page. What you’ve got to say about your research could fill hundreds of pages, so you already have to cut that down. Once you’ve said what you need to about the actual work it’s probably already past the submission deadline, and you don’t want to spend forever writing an intro that will just end up costing you more pages. It’s basically going to fit into whatever space is left to round the paper to the next full page.
> I agree these are annoying patterns, but I honestly don’t notice them.
Right, these things have become a bit ritualized. To continue flogging the religious analogy a paper is like the Mass, you do your readings first, then you chant a bit, then you tell your audience an uplifting story, etc. You notice only when a step is skipped, otherwise the steps don't feel redundant but comforting. :-)
In CS, another sin is that you have to "justify" the significance of the results even in theory conferences.
Hence many papers contain exaggerated claims with respect to practicality, importance and so on.
Another sin is that the results need to be "difficult" and "surprising" in order to publish. Hence, if you present your story in a simple-to-understand fashion, you run a high risk of rejection. Better not simplify your results before publishing -- keep all original notation, even if you figured out you do not need that many indices.
This has become a dogma and there is little chance of all this nonsense stopping anytime soon.
It is refreshing to read old papers that merely get to the point and are significant while being nice to read.
As someone with a background in music within the Academy, where acoustics is an undeniable physical foundation for the making of meaning, and semantics are frequently well established, but the application, usage and interpretation is entirely up to humans...I have (good/bad?) news for computer science:
(from my relatively uninformed perspective)
As an academic discipline, it seems that computer science is quickly returning to its roots in philosophy of logic, now with a strong connection to sociology.
In journalism, if it bleeds, it leads.
In academia, if it begins as an inscrutable mess but unlocks to a "Eureka! It's so simple!" moment in the audience, it's a sure hit. If you've found it, expound it?
Like in journalism, a lot of academia chases its own tail. Publish the bleed/Eureka moment regardless of its inherent value, as long as it produces the desired consumption by the audience.
"The fool looks at the guru who points at the moon" and all that. Lots of focus on how to go about pointing, often too little focus on the searching.
I don't agree with the author. For me each of the sins have their goal that isn't in what they state. I wonder what the author thinks of this almost 25 years later.
-----
* The grandmothering: Too often have I read an abstract, not understood it (since an abstract is allowed to be dense), and quit on these first lines orienting the paper in the field . If it's your field these lines don't cost, if you're a newcomer, or from another field, you get the keywords you need to know before starting. And often you know this paper isn't what you were looking for.
As for the near-meaninglessness of this sentence: look up the first sentence of any book. You can't put 100 pages in one sentence.
* The table of contents: writers can't actually insert a table of contents, yet a paper needs it. True, nobody cares what's in Section 5, yet without this sentence you don't know when it will end, you don't know what you get. You care about how the content escalates. Also note that each of the sentences is more than just the title of the section. The actual title of Section 6 is just 'Time complexity'.
* Conclusions that don't: His solution is literally the opposite of what is taught. Yes to a perspective, no to new information. Also his example is incomplete, three more sentences follow that are not summarizing.
* Table of contents: The 'inline' ToC, proposed by the author, is way more aesthetical and terse.
* Grandmothering: Don't grandmother. Either be pedagogical or skip to the meat.
* Conclusion: I nowadays prefer the paper-paper-paper format: The abstract is the whole paper, the introduction is the whole paper and the paper is the whole paper. Just the "zoom" level differs. Hence, the conclusion should really bring something new.
You raise good points, but I'm largely with the author.
* grandmothering: The author's examples weren't actually about orienting the paper in the field. They were giving redundant background material on the field itself. I think the distinction was not made clear. If I were to speak for the author, I'd say that it's not about dropping these introductory sentences, it's about making them say something useful to somebody. Orienting a paper's place in the field is useful. Telling me that distributed computing deals with scalable problems is not.
* I have never, ever used the textual table of contents to find my way around. If it was guaranteed that section numbers were included, I might train myself to rarely get some use out of it. If there are no section numbers, it is worse than useless, and sometimes indistinguishable from bragging: "first, we propose a novel algorithm. Next, we prove that it is brilliant. Later, we show how it's what you wish you could have come up with but didn't. Finally, we describe what a loser you would have to be to not recognize our brilliance."
* It may be the opposite of what is taught, but this is the one that I feel most strongly that the author is 100% correct. If you want a summary, read the abstract. If you want rambling about where this fits in with other stuff, read the introduction. The conclusion may not be needed, but at its best, it's where the gold is. It's not about what you did, it's about why you did it and why other people should care. The rest of the paper is about closing off an open problem. The conclusion should be about what new things your contribution opens up.
The exhortation against new information is still accurate, it's just that it's more nuanced than that. Don't put in new information that's relevant to the problem you're addressing and the solution you've come up with. But do put in new information about things not addressed in the rest of the paper. There's prior work, which should be referenced in the introduction. There's your work, which is described in the body of the paper. There's future work, which is for the conclusion. There's also the layer above, the wider meaning and ramifications of your work; that's also for the conclusion. "What useful insight can I provide as a result of burying my head in this problem for months or years?"
They were about orienting the field in the world. Distributed computing could (unlikely) have other meanings ('a laptop for every child?'). Redundant for you or me is not redundant to everybody.
> Telling me that distributed computing deals with scalable problems is not.
Yet distributed computing is a highly specific construct and scalable is a regular English word. Imagine a biology PhD-student whose advisor tells him to read this paper to improve his code.
> toc
But it isn't to find your way around. It's to tell what's in store and what can be skipped. Also, I have never seen a toc that was bragging. They are dry because they are scripted.
'First we propose a novel algorithm': I should definitely read this carefully and not just check if it's still the same as before. 'Next we prove it is brilliant': (Leaving aside this won't every get published) Correctness proofs are important, but today I don't care, skip. 'Later we show ...' (Now your argument is just breaking down.) But apparently there is no time complexity in this paper and there are no experiments. I really needed a practical paper. Lets just leaf through and check the images to see if there is experimental data.
> Conclusion
True it's not about what you did. But everybody knows the conclusion is read without the paper and even without the introduction. You must to say what you did as context before saying why others should care. Which is what I meant with my previous comment, only two fifths of the conclusion is summarizing. And you can't just leave those two sentences out.
And future work, if done well, should not be new information if you've read the paper. All of it should be things that follow naturally from things which were unaddressed. Finally, the wider meaning is also not new (hard) information.
You make reasonable points. I'm just relaying my impressions based on my experience reading papers. Perhaps some topics have strengths/weaknesses in different areas.
> But everybody knows the conclusion is read without the paper and even without the introduction.
But not without the abstract! Unless the abstract is so opaque that you're just reading the conclusion in hopes that they'll have written something intelligible, somewhere. But that's doing it wrong.
I'll assert that the Right way to read a paper is: abstract first. Stop there if that's enough to tell you it's not relevant or interesting. If it piques your interest, conclusion next. Probably stop there, but if it's really intriguing, tackle the introduction next (but don't get your expectations too high; median introduction quality is pretty low.) Stop there unless it's really up your alley.
If the abstract doesn't pique your interest, but it's because you can't extract any sense from it, then next is either the introduction or the conclusion depending on what part most needs clarity.
> Also, I have never seen a toc that was bragging. They are dry because they are scripted.
I don't think the intent is to brag. And I think it's defensible; if you're writing a paper, you should write it from a perspective of believing that it is an important addition to Knowledge. I would hate to read an overly humble paper. People definitely overshoot, though, and claim that they're resolving a much larger chunk of the overall puzzle than they are.
Importance and significance are not good assumptions to start with when reading.
Can't speak for others, but I rarely, if ever, look at the table of contents paragraph. The reason is that I find it faster and more convenient to simply scan the section headings, since most CS papers are relatively short.
The grandmothering complaint misses what I think is the main purpose of the introduction section of a paper: to orient the reader. I’m hoping it tells me something I already know, because how else am I going to build a bridge to the new knowledge the paper promises?
Moreover, it’s really not telling me what I know — it’s telling me what the author knows. If the author has a strange perspective on things I think I know, then it’s going to make understanding the rest of the paper much harder; how can I trust this author about unknown subjects when we can’t agree on topics of which we ostensibly share a common understanding? Such context is especially important when we are talking about the far edges of knowledge.
That was my first thought - unless you're Donald Knuth or something, you're going to have an academic advisor more or less "force" you to insert the "table of contents paragraph" before your paper will be accepted for publishing.
I agree with the overall idea, that many papers in mathematics and related fields could benefit from their authors spending more time on their writing style.
I disagree with most of their suggested ways of doing this.
* Grandmothering: I didn't understand the point here. I think writing an overview sentence in your abstract can be helpful.
* Table of contents in a paragraph: Whatever it's just one paragraph, if you don't like it don't read it
* Conclusions that don't: I think the having first paragraph of your conclusion as a reintroduction is very helpful. I sometimes read only the conclusion, and I often find the summary paragraph at the beginning of the conclusion to be more direct than other parts of the paper. Clearly the example of changing the tenses of the verbs in the introduction and putting this again as the conclusion is inexcusable, but I'd be surprised if that happened other than in the one place the author came across it
Conclusions that don't conclude, but re-state the introduction are bade?
But that just follows from the time-honored recipe for essay writing:
1. First tell 'em whatcha gonna tell em.
2. Then tell 'em.
3. Then tell 'em whatcha told 'em.
To conclude doesn't mean to draw some new logical inference, but just to bring the paper or talk to an end.
You don't introduce anything new in a conclusion.
Not any kind of conclusion.
E.g. a musical symphony will rarely introduce entirely new themes in the last bars. Instead various ending devices occur, like condensed re-statements of themes that occurred previously.
> The dictum is, ``Tell them what you're going to tell them, then tell them, then tell them what you told them.''
He is simply disagreeing with this advice. It's time honored, but people are allowed to have their opinions, and I tend to agree with him on this one.[1]
As an aside, I really dislike Powerpoint presentations that include a TOC[2] and simply repeat (almost verbatim) what they've already talked about. I will acknowledge that some people like this, so I don't complain about it. However, I do think there's a very good reason you don't find TED talks following this format.
[1] Or rather, I think it takes a lot of skill to follow this advice well, and most people simply repeat themselves in a trivial way, which I find pointless.
[2] The only thing it's good for is deciding if I want to listen to the talk at all (e.g. I expect an overview talk and see that the presenter is going to into more detail than I care for).
Authors get pushed into writing like this, then readers learn how to read a scientific paper. The point is: a lot of people put up with this process and don't feel incentivized or empowered to challenge it with their own work. I hope it's painful enough that something better is adopted, but after 25 years it hasn't happened yet.
I'm guilty of sin two. And I can see the op's point. So I can amend, improve.
One sin that ought to be included replete in CS, math, and physics papers my English writing instructor made me stop: parenthetical phrases. Excessive footnotes are another variation.
Readers are not interested in the author's breadth-first association of one fact to 87 other facts.
Fixing this requires two things: knowing associations is certainly good. But know what's for you and what's for the reader. Second, know the point you're trying to make and nail it without bringing in half baked facts or edge cases.
In my papers I cut all that out. I either connect and explain clearly or I omit.
Re: grandmothering: I totally agree with op: if I'm a specialist in the area it's not value add. Like too many Ted talks it's people telling the in crowd what they probably already agree with. If not a specialist it's inaccessible. Either way it's bad, it's waste.
The author seems to value direct, polished prose. Surely some academic writing is direct and polished, but most of it isn't.
Writing an academic paper is the existential obligation of its authors. There's something in there that you want to get across to somebody, but the rest of it be damned. I'd expect the quality of the prose to be a low priority, not unlike in much developer documentation, school book reports, speeches, and other writing that is mostly filler to meet an obligation.
At first I thought the author was purposefully eschewing any useful formatting to make a point later about how this work itself would be easier to read if a minimal amount of formatting was provided to make it more palatable to those reading it, but no, upon checking other pages of theirs, and even loading up developer tools in case some CSS file was failing to load (and finding none), it seems this author is blind to their own shortcomings in communication.
Extremely basic HTML pages (is this brutalist? minimalist?) is pretty much the fashion for CS people isn't it? I mean, I get it if it's not your cup of tea but it's pretty much standard formatting, dark font on light background, readable font size. The only thing I can complain is the long lines but I resize my browser window and, voila!
Again, each to his own, but I find it pretty ironic to find this comment here of all places. HN isn't that far in terms of design either. This site spent a bit more time choosing colors but font is too small, and lines run a similar length.
Curious to know what minimum formatting you expect.
HN does get called out for that, and additionally, HN is not presenting a critique on communication.
> Curious to know what minimum formatting you expect.
For a CS professor? Little to none. For a CS professor that is providing criticisms in how papers are presented as "sins"? A minimal amount of formatting to provide some readability, such as what they would likely critique in any paper they expected others to read, would be a good minimum.
As I noted in another reply, once you start critiquing communication issues, you're fair game. Otherwise, I could care less, and I'm not usually one to complain about site design or usability, because honestly I generally prefer it somewhat minimal (but "minimal" that becomes "somewhat unreadable" over time is something that can and should be avoided).
This is how HTML renders by default - I guess it's an artifact of times when not everyone had a 2 foot wide screen. Fortunately many browsers/extensions can fix this for you with reader mode.
This seems somewhat ungenerous. This article was written in 1997, barely a year after the CSS standard was released. If anything, it's a failing of browsers to not render basic html in a palatable way.
One day, I truly wish to come to hacker news and not have this type of comment be the first thing that people decide is worth posting.
I don't think it is. I thought about it quite a bit before posting, actually.
The entire page I'm critiquing is itself a critique of poor methods of communication. That's the only reason I bothered to post a critique at all. If someone's going to post a rant about how people aren't writing their papers well, I definitely see them as fair game for a critique on how they chose to communicate that to the reader.
You can try to equate what I did to someone complaining that some site explaining a math concept breaks their scrolling, or that the color scheme is hard to read on mobile for some game blog, but I think this is different. When the subject matter is communication, and that communication is done in a way which aged very poorly, I think that's worth pointing out. I doubt this person would have submitted a paper with poor font sizing and spacing, because those are fairly well established as to what's acceptable and what isn't, yet they haven't bothered to make sure their own writing doesn't confirm to many other widely accepted sins.
For what it's worth, he has another, newer page at http://people.eecs.berkeley.edu/~jrs/ with links to items as new as in 2021, yet still prominently links this same page and doesn't have any formatting on the rest of their content.
In my eyes, that makes them fair game for criticism of this sort, and I think that also makes it relevant.
Nowhere in the essay you read does the author criticize presentation of text on the page. He critiques the actual content of technical papers. You are critiquing his use of CSS (or lack thereof).
I think it's a bit more nuanced that that, since he's also talking about placement of points and descriptive sentences and how it turns into a type of table of contents, which is a bit of both content and presentation in my opinion, but I could see how you might differ on that point. To me, data presentation and making it palatable to those intended to consume it is important, and not easily teased apart from the data itself when viewed with respect to communication.
For what it's worth, if you look at the source of the page, you can see how he actually does seem to care about line length with respect to legibility for himself, it just doesn't seem to extend to something he cares about with respect to his readers.
Unless I misread it, if a project is deemed to have an "FBA" then the project leader is an "FN", in the author's opinion. And yes, some such projects have been explicitly called out.
The bigger and more interesting point is how to navigate the world of research where everyone is convinced their way is the only right way. I paragraph-TOCs, but my reviewer insists on including it. This article is an example.
We need a better way to establish consensus for things that can be standardised and we need more taste and tolerance for things where opinions can differ.
I’ve tried writing papers without conclusions, only to have reviewers call out that “the paper has no conclusion.”
As for the comment about bad project names and acronyms: Jonathan is most famous for developing the “Triangle” code for Delaunay triangulation, and “Triangle” is of course impossible to Google. Should have chosen a more distinct acronym! :)
My view, from math, computing, and computer science is (1) that the author is being too critical and often throwing out a small but good baby with some not very dirty bathwater and (2) that he is not mentioning some larger problems, worse "sins".
Here would be my list of the worst sins or how to avoid them:
(1) A term is a word used with other than a standard dictionary definition. Technical fields are awash in terms. Make sure to try hard to define all the terms you use; with some judgment applied, can omit definitions of some terms certainly well understood by any reader with enough background to get anything from the paper. Poorly or undefined terms can be one of the best ways to lose readers. Here, hoping to get more readers, maybe inviting them into the field, bend over backwards in defining terms, that is, maybe give some term definitions for readers who, really, have little hope of getting much from the paper -- at least, when such a reader gives up they won't blame the author!
In addition, for any term new or relatively new to the field, with some judgment, might also include for the term motivation of its importance and examples of its usage -- i.e., make clear the importance, relevance, value, usage, etc. of the term.
(2) For nearly all acronyms, standard in the field or not, for the first use of the acronym include what it abbreviates. Here to be sure are doing well on this issue, strain and bend over backwards and include, say, even TCP (transmission control protocol), SMTP (simple mail transfer protocol), CPU (central processing unit) -- sure, I'm suggesting bending over backwards. Several slaps on the wrist, an hour in the corner with wearing a dunce cap, and a coating of tar and feathers for each acronym used but not defined with what it abbreviates.
(3) For how to write math, in two parts, (A) and (B):
(A) Take some theorem proving courses from some of the most precisely written texts, say, P. Halmos, Finite Dimensional Vector Spaces, W. Rudin, Principles of Mathematical Analysis, Neveu, Mathematical Foundations of the Calculus of Probability, E. Nering, Linear Algebra and Matrix Theory, Royden, Real Analysis where do a lot of the exercises as homework and where the professor DOES read and remark on your writing. Neveu was a Loeve student at Berkeley. Nering was an Artin student at Princeton. As I recall, Rudin's background was in Austria, although I don't know who his professors were. Of course, Royden was long at Stanford. For more, if have time and insist on some really good examples, read some of Bourbaki.
By the way, on use of we, that is standard. So we might have,
"Given topological spaces X and Y and a function f: X --> Y, we say that function f is continuous provided for each set B open in Y f^(-1)(B) is open in X.
So, that's a vanilla example of using we in mathematical writing.
(B) Do some things none of those texts do: Include some intuitive views, some helpful pictures, motivation via applications in math and also outside math, and outlines of research directions.
There is a lot of question about how appropriate is suggestion (B); in math my guess is that there is no question about the relevance, wisdom, importance, value, etc. of suggestion (A).
For the goal of writing math, suggestion (A) is important: Tough to expect good success without the texts I listed or other texts written with similar care. That level of care is extreme, tough to find and learn, and much tougher to do. Writing math with the care of those texts seems to have been understood and practiced significantly often only after about 1950 or 1940. And for at least one course from at least one such text, DO have the good homework grading of a good math professor.
Personal experience and lesson: While I'm not much interested in being a professor, I have published some papers, and from getting those papers reviewed my guess would be that about half of the reason the papers passed review, and they always did with no significant revision or difficulty, is that I wrote the math with nearly the care and precision of, say, W. Rudin. Point: To critical readers, any lapse in that level of care and precision can be like a worm in a baked apple, perhaps otherwise terrific from brown sugar, butter, etc. Or, might guess that, in nearly any field, the good work is less than 10% of the total, maybe less than 1%, with the rest flawed, maybe as bad as that apple with a worm. In writing math, it is way too easy to be in the bottom 99% or 90% just from the care and precision of the writing, and suggestion (A) is IMHO (in my humble opinion) a good way to have at least the writing quality keep you in the top 90+%.
For math used in computer science, for how to write that math carefully, there are of course examples from D. Knuth.
Unnecessary verbosity should be at the top of the list. Without clarity (brevity being the soul) the rest fails.
They say that the google crawler won't take you seriously unless you include your life story as prelude to that recipe for pb&j. Is this making everything less clear?
Regarding "grandmothering": I agree with the criticism of the first example. Explaining basic points of the field in a vague way is obviously not helpful. The second example is not as compelling. The key point is that the "..." after "In recent years, the study of preconditioners for iterative methods for solving large linear systems of equations, arising from discretizations of stationary boundary value problems of mathematical physics, has become a major focus of numerical analysts and engineers" usually contains a string of citations. These citations serve to point the reader to the recent works mentioned in the sentence, which may not be readily accessible to someone who doesn't actively do research in that area but is otherwise knowledgeable about numerical computing.
In particular, the author reasons such introductions are bad because "the bulk of the paper is accessible only to those sufficiently expert in the field to know everything in the first two paragraphs of the introduction cold." But this is just wrong. There are plenty of math/physics papers where I can follow the arguments line-by-line, but I don't know the state of the art in the field or why the problem under consideration might be important. I don't think I am alone.
Regarding, "A table of contents in a paragraph": I think the author is partially correct. For short papers, it's perfectly fine to fold this part into the introduction (e.g. in the outline of the proof). But for longer works where the proof is decomposed into multiple lemmas and sub-lemmas, these can be very useful. If one writes the proof in a very clear and structured way, then maybe such "shotgun summaries" can be avoided. But this is not always possible.
Regarding conclusions that only repeat the introduction: I agree here.