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.
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.
> 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?"
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.
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.
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?
spekcular|4 years ago
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|4 years ago
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|4 years ago
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|4 years ago
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|4 years ago
kkylin|4 years ago
mjw1007|4 years ago
jgwil2|4 years ago
Wouldn't they be better off as an actual table of contents though, rather than in paragraph form?
porcoda|4 years ago
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.
k0stas|4 years ago
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.
foobarian|4 years ago
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. :-)
truly|4 years ago
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.
IggleSniggle|4 years ago
(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.
rrobukef|4 years ago
-----
* 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.
anticristi|4 years ago
* 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.
sfink|4 years ago
* 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?"
anon946|4 years ago
ModernMech|4 years ago
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.
pfortuny|4 years ago
jeffwass|4 years ago
commandlinefan|4 years ago
anticristi|4 years ago
"The authors of this paper chose not to include a table-of-contents in a paragraph, as promited by ... ."
joe__f|4 years ago
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
kazinator|4 years ago
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.
BeetleB|4 years ago
> 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).
Robotbeat|4 years ago
aimor|4 years ago
scrubs|4 years ago
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.
MathMonkeyMan|4 years ago
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.
kbenson|4 years ago
skytreader|4 years ago
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.
grumbel|4 years ago
jandrese|4 years ago
jgwil2|4 years ago
credit_guy|4 years ago
049e18103424|4 years ago
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.
onhn|4 years ago
Nothing like personal attacks to get your point across. Well done author.
jgwil2|4 years ago
jmmcd|4 years ago
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.
evouga|4 years ago
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! :)
graycat|4 years ago
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.
paulpauper|4 years ago
swayvil|4 years ago
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?
toxik|4 years ago
lincpa|4 years ago
[deleted]