[%TAGS (074db819ec% %074db819ec) %]

(074db819ec% subtitle %074db819ec)


(074db819ec%|loc%074db819ec)chronological(074db819ec% END %074db819ec) (074db819ec%|loc%074db819ec)Thread(074db819ec% END %074db819ec) 
(074db819ec% IF user.email && action == 'arc' %074db819ec)
(074db819ec%|loc%074db819ec)Reply to sender(074db819ec%END%074db819ec) (074db819ec%|loc%074db819ec)to list(074db819ec%END%074db819ec)

(074db819ec% IF user.email == 'Gert Wollny wollny@cns.mpg.de' || is_owner %074db819ec) (074db819ec% END %074db819ec)
(074db819ec% END %074db819ec)
Steve Probert wrote:
> In the majority of cases a description in plain language is
> much clearer and far more effective.

"plain language"  - sounds great, but , uhmm ... , how do you define
"plain language"?
I hope you do not mean "laywer speak", the language, patant applications
are usally written in.
This is as much "plain language" as C ( or better C++, 'cos they always
use templates for broader claims *g* ).

IMO, to understand software, a /* commeted */ working implementation is
lots better then only a description in "plain language". Especially
since "plain language" is not well defined.

Just my $0.02

Gert Wollny





(074db819ec%|loc%074db819ec)Archive powered by(074db819ec%END%074db819ec) MhonArc 2.6.16.

(074db819ec%TAGS [% %]%074db819ec)