Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three sins of authors in computer science and math (1997)

cs.cmu.edu

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Three sins of authors in computer science and math (1997)

#21

Post by kyawzazaw »

skytreader wrote: post #8
kbenson wrote: post #2

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 t…

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…

It is. CS professors are known to do these.

Re: Three sins of authors in computer science and math (1997)

#22

Post by aimor »

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.

Re: Three sins of authors in computer science and math (1997)

#23

Post by agumonkey »

kyawzazaw wrote: post #21
skytreader wrote: post #8

Earlier quoted context omitted.

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…

It is. CS professors are known to do these.

oleg kyseliov is famous for that https://okmij.org/ftp/

Re: Three sins of authors in computer science and math (1997)

#24

Post by tikhonj »

jgwil2 wrote: post #17
spekcular wrote: post #14

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 m…

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

At least in CS venues, page limits disincentivize formatting that takes up more space—even when it's more readable.

Re: Three sins of authors in computer science and math (1997)

#25

Post by onhn »

jgwil2 wrote: post #16
onhn wrote: post #10

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

No one is named, so how does this constitute a personal attack?

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.

Re: Three sins of authors in computer science and math (1997)

#26

Post by spekcular »

jgwil2 wrote: post #17
spekcular wrote: post #14

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 m…

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

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.

Re: Three sins of authors in computer science and math (1997)

#27

Post by kazinator »

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.

Re: Three sins of authors in computer science and math (1997)

#28

Post by rrobukef »

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.

Re: Three sins of authors in computer science and math (1997)

#29

Post by ModernMech »

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.

Re: Three sins of authors in computer science and math (1997)

#30

Post by anon946 »

rrobukef wrote: post #28

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,…

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.
Post reply on HN