Comment One practical aspect (Score 1) 337
...of this issue:
For several years in the '80s, I volunteered for an organization called Recording for the Blind, doing just what it said: recording the equivalent of audiobooks for blind "readers." Most books, at least then, didn't come in Braille editions, so RFB aimed to plug the gap. Although I'd imagined reading novels and poetry, because I had developer experience they put me to work recording textbooks and such on how to code.
NO ambiguity was acceptable; if I tried to fudge something, a staff member monitoring the process would stop me, and I'd have to go back and record it again, for later editing into the final product.
Some of the examples above would definitely have qualified as "fudging." For instance, I couldn't read shared_ptr as either "shared putter" or "shared pointer"; it would have to be something like "shared underscore pee tee arr." And if the text (and/or the language itself) made an issue of case-sensitivity, then Shared_Ptr would NOT be pronounced the same way as shared_ptr -- I'd have to distinguish the pronunciations by pointing out the upper/lowercase differences. Over time, we came up with conventions to simplify this -- like recording an intro explaining the conventions used by the particular text, so every single instance didn't need to be spelled out. But it was never "easy" or "unimportant"; on the other hand, while I derived satisfaction from my volunteer work, thanks to the RFB experience I can't say that I regretted eventually moving away from that geographic area.
Aside: I once took a course in developing queries for PeopleSoft, back before Oracle acquired them. One of the standard table names was "DEPT_TBL"; the instructor always pronounced this "department tibble" -- it drove me CRAZY until I figured out what the hell he was talking about.
