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.
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.
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.
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.
Wouldn't they be better off as an actual table of contents though, rather than in paragraph form?
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’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 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.
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.
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. :-)
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.
(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.
-----
* 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.
* 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.
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.
"The authors of this paper chose not to include a table-of-contents in a paragraph, as promited by ... ."
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
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).
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.
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.
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).
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.
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.
Nothing like personal attacks to get your point across. Well done author.
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.
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! :)
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.
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?
