Comment by rrobukef | Hacker News Reader

Comment by rrobukef | Hacker News Reader

Parent Full thread

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.

I still give these sins to my PhD students.

* 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?"

> * grandmothering:

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.

You got it. It's like compression/information-content: add value aligned with thesis. Eliminate noise.

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.

Reply on news.ycombinator.com