4 ms·

Papers should have a glossary or define terms inline with parentheses: Yet Another Acronym (YAA). It's annoying to jargonify, paper or not, because it doesn't

Papers should have a glossary or define terms inline with parentheses: Yet Another Acronym (YAA). It's annoying to jargonify, paper or not, because it doesn't help reduce the cognitive load of the reader and it makes the paper less accessible.

tablespoon 6y ago
No, not really. The intended audience for a paper like this is not a layman who needs a glossary, but a fellow expert fluent in the field's jargon.
- airhead969 6y ago
  Forget the "layman" elitist snobbery. There are people from adjacent fields and people in other fields who read such papers. Furthermore, that merely reinforces the "Latinization" of fields rather than making knowledge reasonably-accessible to all who wish to read it. In addition, prepress processing such a paper could easily add a glossary of term and/or hyperlinks mechanically.
  - tablespoon 6y ago
    It's not snobbery, but an acknowledgement that jargon exists for a reason, and that reason isn't to make the writing opaque to outsiders. You're probably a software engineer. Are you going to write out REST (REpresentational State Transfer) in every design document you put up on your company wiki for your team that describes one, just in case a non software engineer wants to read it? Are you going to explain the concept? No, you're going to write for your audience, and stuff like will get their way. If you want to read infra-disciplinary writing, you need to be willing to do the work to familiarize yourself with the concepts and terms of the discipline that you don't understand, instead of expecting everyone, always, to offer close-at-hand definitions just in case. That latter expectation is only reasonable for writing targeted at a general audience.
    - SilasX 6y ago
      > Are you going to write out REST (REpresentational State Transfer) in every design document you put up on your company wiki for your team that describes one, just in case a non software engineer wants to read it? No, because that's not disseminated to a broader community. If it were, I'm going to link a standardized reference document that defines the terms, like they do in RFCs. Edit: Actually, even with such an "internal" document, my preference would be to overexplain rather than underexplain, and define an acronym (or neologism I had learn myself recently) before using it. REST is a special case though, in that defining out the acronym doesn't actually help explain how people use it.
dragonwriter 6y ago
> It's annoying to jargonify, paper or not, because it doesn't help reduce the cognitive load of the reader and it makes the paper less accessible. Actually, jargon does reduce cognitive load; that's why all specialized communities have it to make fine distinctions that are relevant in the community more concisely and precisely than less specialized language does.
deleted 6y ago
[deleted]
msla 6y ago
Nobody's going to take you by the hand every time you want to read something above you. Have some humility.

tablespoon 6y ago

No, not really. The intended audience for a paper like this is not a layman who needs a glossary, but a fellow expert fluent in the field's jargon.

airhead969 6y ago
Forget the "layman" elitist snobbery. There are people from adjacent fields and people in other fields who read such papers. Furthermore, that merely reinforces the "Latinization" of fields rather than making knowledge reasonably-accessible to all who wish to read it. In addition, prepress processing such a paper could easily add a glossary of term and/or hyperlinks mechanically.
- tablespoon 6y ago
  It's not snobbery, but an acknowledgement that jargon exists for a reason, and that reason isn't to make the writing opaque to outsiders. You're probably a software engineer. Are you going to write out REST (REpresentational State Transfer) in every design document you put up on your company wiki for your team that describes one, just in case a non software engineer wants to read it? Are you going to explain the concept? No, you're going to write for your audience, and stuff like will get their way. If you want to read infra-disciplinary writing, you need to be willing to do the work to familiarize yourself with the concepts and terms of the discipline that you don't understand, instead of expecting everyone, always, to offer close-at-hand definitions just in case. That latter expectation is only reasonable for writing targeted at a general audience.
  - SilasX 6y ago
    > Are you going to write out REST (REpresentational State Transfer) in every design document you put up on your company wiki for your team that describes one, just in case a non software engineer wants to read it? No, because that's not disseminated to a broader community. If it were, I'm going to link a standardized reference document that defines the terms, like they do in RFCs. Edit: Actually, even with such an "internal" document, my preference would be to overexplain rather than underexplain, and define an acronym (or neologism I had learn myself recently) before using it. REST is a special case though, in that defining out the acronym doesn't actually help explain how people use it.

dragonwriter 6y ago

> It's annoying to jargonify, paper or not, because it doesn't help reduce the cognitive load of the reader and it makes the paper less accessible. Actually, jargon does reduce cognitive load; that's why all specialized communities have it to make fine distinctions that are relevant in the community more concisely and precisely than less specialized language does.

deleted 6y ago

[deleted]

msla 6y ago

Nobody's going to take you by the hand every time you want to read something above you. Have some humility.