Comment by xelxebar | Hacker News Reader

Comment by xelxebar | Hacker News Reader

Parent Full thread

While gatekeeping is definitely a thing, I really suspect it's not the major incentive here.

In writing (both prose and code!) there is always a question of target audience, which inevitably excludes the not-target audience. Personally, for a field in which I'm an expert, it's really annoying to continually wade through introductory material and hand-holding just to get to some small nugget of substance. In that case, I'm definitely not the target audience, so I'll go looking for another communications channel that offers the compressed/elegant/general/abstract/terse formulations I desire. Please don't then insist that I'm being unfair and exclusionary if you're not the target audience on those specific communications channels.

For math papers and whatnot, whitepapers are like the one established channel for experts, while everyone else has textbooks, introductory pamphlets, blogs, youtube videos, etc. I agree, however, that there are cases where non-experts could benefit from knowledge siloed within expert communication channels, but this is an unfortunate systematic side-effect not malice.

Honestly, with software development, I find it disappointing that our social conventions currently conflate "readability" with "comfort and familiarity to Generic Programmer" instead of something more useful like "facilitates domain understanding and insight to the primary developers".

The target audience point is fair. There are basic concepts that I don't bother defining in any paper I write, and I'm sure there are people who would make the same argument about them that I'm making here. But I'm not suggesting writing everything like "An Extremely Gentle And Slow Introduction to X, With Lots of Reassurances That You Can Do It".

The question probably comes down to how accessible a paper should be. Personally, I think a reasonable bar is something like: a third-year PhD student in your broad area should be able to skim the paper and say a couple of paragraphs about what's happening and why it matters, and upon reading the paper more closely, present it in a seminar and defend it at least a couple of questions deep. IMO, most papers are not at this level, and are instead pitched at actual experts.

I think my point (and TFA's point as well) is that going from an experts-only paper to a seminar-ready one is actually not a ton of text. It might increase a paper's length by 5%. It's not about making everything longer, but adding enough context and signposting that the story can be followed at multiple levels, from the 5-minute pitch you'd get at a poster session to the every-detail one the author has. So I think we can have a paper that both the grad students and experts like.

I think doing this takes some skill and effort, which is well within the reach of most of the people who can write these papers, but way less effort is expended on this non-technical aspect.

I’ve started to keep a collection of readable papers (mostly engineering/experimental science, but a little bit of more theoretical work as well) that cover what I consider to be pretty foundational concepts, because additional citations are ~free and it at least gives an entry point for readers that are on the edge of the target audience.

As a consequence, I’ve read papers that were written anywhere from the late 19th century to just a year or two ago. In my experience, the older papers tend to be more understandable at a conceptual level but more modern ones tend to be more precise with the details. There is likely some survivorship bias here, though, as there has been more time for the worst of the old papers to be forgotten.

The writing style has also changed a lot— The older papers present things in a much more narrative way, and it can be a challenge to bring the kind of motivational context that allows into a paper that would feel at home in a modern publication.

> I’ve started to keep a collection of readable papers

Are these shared / mentioned anywhere?

A resource like this would be super helpful.

I would also be interested in reading some of these examples!

> Honestly, with software development, I find it disappointing that our social conventions currently conflate "readability" with "comfort and familiarity to Generic Programmer" instead of something more useful like "facilitates domain understanding and insight to the primary developers".

It's sort of a similar effect: most software is written by software people for other software people, just like most math is written by math people for other math people.

I personally have had the experience more than once of a mathematician apologizing for their code style but then handing me code that I find to be more straightforward and readable than usual.

What specific conventions do you think would facilitate domain understanding and insight?

Reply on news.ycombinator.com