I don't think this really matters. What matters much more so is having good findings.
Three sins of authors in computer science and math (1997)
41–50 of 62 posts
Re: Three sins of authors in computer science and math (1997)
#42I 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
Re: Three sins of authors in computer science and math (1997)
#43At 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…
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.
I don't think it is. I thought about it quite a bit before posting, actually.
The entire page I'm critiquing is itself a critique of poor methods of communication. That's the only reason I bothered to post a critique at all. If someone's going to post a rant about how people aren't writing their papers well, I definitely see them as fair game for a critique on how they chose to communicate that to the reader.
You can try to equate what I did to someone complaining that some site explaining a math concept breaks their scrolling, or that the color scheme is hard to read on mobile for some game blog, but I think this is different. When the subject matter is communication, and that communication is done in a way which aged very poorly, I think that's worth pointing out. I doubt this person would have submitted a paper with poor font sizing and spacing, because those are fairly well established as to what's acceptable and what isn't, yet they haven't bothered to make sure their own writing doesn't confirm to many other widely accepted sins.
For what it's worth, he has another, newer page at http://people.eecs.berkeley.edu/~jrs/ with links to items as new as in 2021, yet still prominently links this same page and doesn't have any formatting on the rest of their content.
In my eyes, that makes them fair game for criticism of this sort, and I think that also makes it relevant.
Re: Three sins of authors in computer science and math (1997)
#44I 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,…
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?"
Re: Three sins of authors in computer science and math (1997)
#45At 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…
> HN isn't that far in terms of design either.
HN does get called out for that, and additionally, HN is not presenting a critique on communication.
> Curious to know what minimum formatting you expect.
For a CS professor? Little to none. For a CS professor that is providing criticisms in how papers are presented as "sins"? A minimal amount of formatting to provide some readability, such as what they would likely critique in any paper they expected others to read, would be a good minimum.
As I noted in another reply, once you start critiquing communication issues, you're fair game. Otherwise, I could care less, and I'm not usually one to complain about site design or usability, because honestly I generally prefer it somewhat minimal (but "minimal" that becomes "somewhat unreadable" over time is something that can and should be avoided).
Re: Three sins of authors in computer science and math (1997)
#46I 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…
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.
Re: Three sins of authors in computer science and math (1997)
#47The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model
https://github.com/linpengcheng/PurefunctionPipelineDataflow
1. Mathematical prototype: Its mathematical prototype is the simple, classic, vivid, and widely used in social production practice, elementary school mathematics "water input/output of the pool". My theory rebuilt the theoretical foundation of the IT industry, It makes the computer theory system fully & perfectly related to mathematics in a simple and unified way: from hardware integrated circuits and computer architecture, to software programming methodology, architecture, programming language and so on. It solve the most fundamental and core major problems in the IT industry: The foundation and core of the IT theory lack mathematical support.
2. Software and hardware are factories that manufacture data, so they have the same "warehouse/workshop model" and management methods as the manufacturing industry.
3. Software and hardware are a unified architecture: "warehouse/workshop model".
3.1. From a static point of view, it is a star.
3.2. From the perspective of dynamic runtime, it is a dynamic tree Gantt chart, like a rushing river system.
3.3. the "Warehouse/Workshop Model" will surely replace the "von Neumann architecture" and become the first architecture in the computer field, and it is the first architecture to achieve a unified software and hardware. Because "von Neumann architecture" lacks mathematical model support, it is impossible to prove its scientificity.
- Follower: Apple M1 chip
- HPE Cray Supercomputer likes it twice at twitter in 2021-04
4. The scheduler (scheduling function) dynamically plans the order of completion of tasks according to the Gantt chart algorithm, and calls the workshop to complete the assigned tasks. This approach is the most efficient, and there is no resource competition and transaction conflict.
4.1. From the perspective of system architecture, it is a warehouse/workshop model fractal system.
- 10 Principles of the model
4.2. From the perspective of component, it is a pure function pipeline fractal system.
- 5 basic pure function pipeline data flow components
- An interconnected pipeline world based on a fully standardized data interface .
- Like EDA, it is integrated and automated that the design and development of software and hardware.
5. Five Aesthetics: In the IT field, only it and binary system fully comply with these 5 aesthetics.
6. The unification with classic AI, modern AI, explainable AI, and law model
7. Basic quality control: Like the manufacturing industry, Non-IT professionals can also perform basic quality control.
8. It has a wide range of applications, from SOC to supercomputer, from software to hardware, from stand-alone to network, from application layer to system layer, from single thread to distributed, from general programming to explainable AI, from manufacturing industry to IT industry, from energy to finance, from cash flow to medical angiography, from myth to Transformers, from the missile's "Fire-and-Forget" technology to Boeing aircraft pulse production line technology.
Re: Three sins of authors in computer science and math (1997)
#48I'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.
Re: Three sins of authors in computer science and math (1997)
#49Conclusions 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 conclusio…
The author did acknowledge what you say:
> 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).
Re: Three sins of authors in computer science and math (1997)
#50I 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,…
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 somebo…
You got it. It's like compression/information-content: add value aligned with thesis. Eliminate noise.