[HN Gopher] Three sins of authors in computer science and math (...
___________________________________________________________________
Three sins of authors in computer science and math (1997)
Author : kcolford
Score : 69 points
Date : 2021-11-17 18:28 UTC (4 hours ago)
(HTM) web link (www.cs.cmu.edu)
(TXT) w3m dump (www.cs.cmu.edu)
| ModernMech wrote:
| 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.
| onhn wrote:
| >Really Bad Acronyms, or FBAs, are spawned by FNPLs (Nerdy
| Project Leaders) when naming new systems
|
| Nothing like personal attacks to get your point across. Well done
| author.
| jgwil2 wrote:
| No one is named, so how does this constitute a personal attack?
| onhn wrote:
| Unless I misread it, if a project is deemed to have an "FBA"
| then the project leader is an "FN", in the author's opinion.
| And yes, some such projects have been explicitly called out.
| aimor wrote:
| 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.
| truly wrote:
| 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.
| IggleSniggle wrote:
| 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.
| toxik wrote:
| Don't follow this advice, it will make it harder to get accept.
| porcoda wrote:
| 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.
| foobarian wrote:
| > 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. :-)
| k0stas wrote:
| > 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.
| ModernMech wrote:
| > The articles "sins" don't matter because experts skip over
| these parts.
|
| 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.
| paulpauper wrote:
| I don't think this really matters. What matters much more so is
| having good findings.
| spekcular wrote:
| 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.
| jgwil2 wrote:
| > 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 wrote:
| At least in CS venues, page limits disincentivize formatting
| that takes up more space--even when it's more readable.
| Ar-Curunir wrote:
| another reason why we should get rid of page limits
| spekcular wrote:
| 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.
| cycomanic wrote:
| 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.
| pavon wrote:
| 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.
| mjw1007 wrote:
| 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.
| Robotbeat wrote:
| It'd be nice to have a bunch of positive examples.
| pfortuny wrote:
| The "table of contents in a paragraph " is almost compulsory in
| any engineering (even applied maths) paper, in most journals...
| As far as I can tell.
| jeffwass wrote:
| I also despise presentations that include a slide with a table
| of contents of the upcoming talk. It's almost always filler.
| anticristi wrote:
| I tend to include a footnote and link to this URL:
|
| "The authors of this paper chose not to include a table-of-
| contents in a paragraph, as promited by ... ."
| commandlinefan wrote:
| 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.
| swayvil wrote:
| 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?
| joe__f wrote:
| 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
| evouga wrote:
| 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! :)
| kazinator wrote:
| 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.
| kbenson wrote:
| 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.
| credit_guy wrote:
| The webpage was written in 1997.
| edflsafoiewq wrote:
| Check out how readable the HTML is.
| 049e18103424 wrote:
| 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.
| skytreader wrote:
| 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.
| kyawzazaw wrote:
| It is. CS professors are known to do these.
| agumonkey wrote:
| oleg kyseliov is famous for that https://okmij.org/ftp/
| jgwil2 wrote:
| 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.
| rrobukef wrote:
| 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.
| anticristi wrote:
| 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.
| anon946 wrote:
| 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.
___________________________________________________________________
(page generated 2021-11-17 23:00 UTC)