From: Richard Newman (richard_at_[hidden])
Date: 2006-09-15 10:34:18
Rene Rivera wrote:
> It's a very sad day when people can again think that customers can
> program. After 25 years of programming this seems to be a recurring
> false pattern. Having done a stint in knowledge based reasoning AI
> development I can tell you that there's a very good reason for the term
> "expert". And for those not familiar with some of the AI aspects in
> this, unless you are willing to make non-programmers write in Esperanto,
> you'll be faced with natural language parsing nightmares.
This is probably off-topic, but I've struggled with this question, and
would like to hear more on this. If it should be in a different list,
please help me to move the discussion there.
It's not so much that I would ever expect laypersons to be able to
program. But I do expect the code to be written such that the layperson
can get the gist, if not every detail, of what it is to be doing.
I have been recently working with the notion that as much as possible
(and that's quite a bit), C++ objects, etc., should be in the terms of
the problem domain: nothing too controversial there. Even if I were
working procedurally in C rather than in OO with C++, I would want my
breakdown to make sense with regard to the domain it is responding to.
Further, and this is potentially the rub, the implementation should also
be in those terms. If we're talking about simpler programs such as
examples in undergraduate CS courses, this is fairly obvious, but it's
real value is in the more complex code, such as in commercial
production. So often code ends up overly complex and rife with
potential error simply because it couldn't be read. If you follow the
principle that a layperson should be able to follow it, then you've
probably thought enough about how you'd explain it that you've done a
better job of organizing the code. I've seen code written for academic
purposes and much of it requires far more from the reader than should
ever be necessary.
Even with C++ templates where the syntax can be very arcane, one might
have to help read past that and I certainly would agree that a detailed,
bit by bit analysis of the consequences of its code construction would
likely be going too far. But again, a reader should be able to follow
the general points of the algorithm and use this as a way to reconcile
specification and expectation with actual code design. In short, the
closer the code is written in terms of the specification (whether
formally or informally developed), the less likely the designer will
miss the mark. The exceptions I allow to this principle generally occur
in performance-critical code.
Finally, I'm not suggesting that code be written such that it matches
the original explanation given by a layperson customer; frequently they
haven't done sufficient analysis to recognize better design
possibilities. However, once a design is developed, the customer should
be able to follow what it is as kind of an application of the Feynman
freshman explanation principle (experts are only experts if they can
explain the subject to a layperson).
So if you have a more rigourous way of determining where the line should
be drawn or if my premise is not supportable, I would be all ears (or
eyes as the case is here).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk