explanations vs. examples vs. design



On Sun, Jan 14, 2007 at 02:12:50PM -0800, Richard Fateman wrote:
> 
> > If you insist f(s):=s[1] should stay as it is but is bad programming
> > then people do deserve an
> > explanation why.
> 
> Yes, they may deserve it, but they probably won't read it and if they read
> it they may not understand it.
> 
> A better approach, I think, is to say:
> 
> How do you pass / and use/ an array, or function array or ..... 
> 
> F(s):= arrayapply(s,1).   Don't use s[1].

I think warnings "not to do x" always work better if the consequences
are at least generally described. For example, if your product says
"do not store near heat" the purchaser will respond in a more
appropriate manner if your warning continues such as "because it
causes spoilage and reduces the life of the product" or "because it
causes explosive combustion".

In this case, the because phrase should be short and relatively
understandable to the unsophisticated.

Having not really followed this thread, I think I'd be very interested
to see such a description. Although I would probably also read and try
to understand a more in depth description, I do agree that a simple
one must come first and foremost because the target audience of maxima
is the mathematically sophisticated, but not necessarily the computer
language sophisticated.

-- 
Daniel Lakeland
dlakelan at street-artists.org
http://www.street-artists.org/~dlakelan