26 ms·

Forget the "layman" elitist snobbery. There are people from adjacent fields and people in other fields who read such papers. Furthermore, that merely reinforces

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.

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.