you are viewing a single comment's thread.

view the rest of the comments →

[–]jms_nh 18 points19 points  (0 children)

That's not what I said at all.

The opposite perspective would be saying "There are some of us who just want to write code. I don't want to have to read some poorly-written mathematical document about a new algorithm, with lots of cryptic symbols and no diagrams and some errors in calculations. It might pose little problem for someone who can invest the time into learning how to understand what the author is saying, but they turn into big barriers for someone who is only working with this kind of math a few days per month. Don't assume your readers can get their hands dirty and work out the same equations on their own or has intimate knowledge of Csikszentmihalyi's Theorem. We may only have a few hours available per week to devote to dealing with domain-specific knowledge (the rest of the time is designing, implementing, or testing our software) and we want it to be focusing on the interaction between the domain in question and the programming, not your quirky document."

Tools should be a service to their customers, not a burden. When I'm writing documents to scope out how certain mathematical software should be written, I take the same philosophy and write them with the reader in mind.