Here's the problem. Many common terms in the programmer's lexicon--i.e., used in information communication and in published texts--are identical to everyday words; others are slight 'distortions' of everyday words (so that if you saw them but weren't a programmer, you'd swear they were misspelled or used incorrectly). It's this latter category that's the focus of my question. Some examples:
persist (a verb, e.g., you 'persist' data by writing it to a RDBMS);
instantiate (invoke a function which creates an object bound to a variable);
deprecate (e.g., replace an old feature with a new one, and leave the old feature in the language temporarily to preserve backwards-compatability)
A colleague and i recently finished writing a book largely directed to programming though the intended audience is mostly (but not exclusively) non-programmers (for instance, marketing managers and other people who often wear ties).
Our editor does not like words like these in the text.
In particular, she feels strongly that terms like the ones i just recited should be replaced with a short descriptive phrase that's more consonant with the conventional business lexicon.
We argue that fidelity to the language of the relevant community is what's most important--i.e., most of the concept we are trying to explain in the book are embodied in these specialist terms, and if the reader doesn't learn those terms then the book will have very little if any practical significance for them because they won't be able to communicate with the specialists who are required to implement the systems described in the book. In addition, we contend that by providing a glossary or endnotes, the reader can easily absorb the unfamiliar terminology.
Arguing from the details though doesn't appear ever likely to persuade either 'side,' and so I would very much appreciate the higher-level views from this community.