>Allen Blackwell wrote:
> Andrew Walenstein wrote:
> > So far as I know, there are no authoritative definitions of
> > what are meant by programming plans, but might I suggest tha[..]
> I guess there must be 20 or more publications describing
> programming plans, including several chapters in the book
> "Psychology of Programming". So isn't it a little misleading just
> to say "there are no authoritative definitions"?
OK, yes, poor choice of words, and probably a little bit of hyperbole.
Perhaps I should have said "precise" or "generative"?
As a weekend psychologist it seems to me that frequently the psych lit.
seems a little too content in defining programming plans by example and
vague English description of the general concept of schematic
representations (slots, fillers, constraints, etc.). We've got a death
grip on what the running total plan is though!
I think this issue is very important for terminology purposes.
Schema theory is a mental representation structure theory, right?
Programming plan theories are additionally *content* theories.
I look at many of the programming plan experiments and they frequently
depend on the experimenter recruiting a few experts to make a judgement
about the programming plans represented in the experimental stimuli.
For instance Dr. Rist's ESP'86 paper mined/knowledge engineered the
representations from experts. This is not assuredly not definition.
THEORY doesn't say what these programming plans are and aren't...or did
I miss the experiments that tested alternate definitions of programming
plans to see which definition best matched the internal representations
of experts?
Are the programming plan theories content to be just structure theories
and only weakly content theories? Obviously not since one frequently
finds general statements about content (ie that programming plans
encode dependencies between data flow, etc.) But a good content theory
would help fill our textbooks with what the expert needs to know. It
would help settle the questions about whether patterns, Prolog tactics,
and software architectures are programming plans.
Right now, its up for some argument, I think, and perhaps the
definition of programming plan will become much more specific (eg. for
Pascal-like languages, or perhaps more appropriately what Drs. Petre
and Winder have written about: some common inner-language pseudocode
not directly related to the implementation language). Hence my original
quip from the hip about "authoritative" definitions.
Now Dr. Rist just provided what in this context I would like in a
definition of a programming plan:
> I define a plan as a backward slice through the code, tracing back
> first through the data and then through the control flow. This defines a
> tree structure, where each branch of the tree is a plan (and the whole
> tree is a plan). This algorithm "pulls out" from the average program the
> plans average, count, sum, and read loop.
This is much better as it gives the outline of a reasonable and
objective procedure for pulling them out of code. It leads to testable
hypotheses about alternative definitions that could be evaluated for a
match to mental representations of experts. It goes some ways as to
saying what things should not be considered programming plans.
In this sense perhaps the most "authoritative" (I don't know what other
word to use) definitions of what programming plans are the plan
libraries by Rich/Waters/Shrobe/Wills, and Rist's Zippy.
Andrew
- Automatic footer for [EMAIL PROTECTED] ----------------------------------
To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss
To join the announcements list, mail [EMAIL PROTECTED] subscribe announce
To receive a help file, mail [EMAIL PROTECTED] help
This list is archived at http://www.mail-archive.com/discuss%40ppig.org/
If you have any problems or questions, please mail [EMAIL PROTECTED]
