[spekcular]

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.

[pavon]

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.

[cycomanic]

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.

[YeGoblynQueenne]

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

[mmmmpancakes]

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.

[kkylin]

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.

[mjw1007]

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.

[jgwil2]

> But for longer works where the proof is decomposed into multiple lemmas and sub-lemmas, these can be very useful.

Wouldn't they be better off as an actual table of contents though, rather than in paragraph form?

[tikhonj]

At least in CS venues, page limits disincentivize formatting that takes up more space—even when it's more readable.

[Ar-Curunir]

another reason why we should get rid of page limits

[jmmcd]

I don't want to review for a conference with no page limits.

[spekcular]

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.