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