Andrew Walenstein is raising important and useful points here.

As far as I'm concerned, whatever the mental representation of a program
might be, it's just a special case of mental representations in general. We
need to consider representations not only of Pascal programs but also of OO,
logic, etc.

Unfortunately the general belief among cognitive psychs is that mental
representations aren't well-shaped formal structures, convenient though that
would be. They are labile, they are influenced by the task, they tend to
involve guesswork and comparisons (like the very well-known simile and
metaphor work), there are elements of spatial imagery in some cases, and so
on.  All of these caveats apply to mental representations of programs.

Rob Rist's definition is a model ('model' in the sense that normal
distribution theory is used as a statistical model). It seems to fit quite
well for many purposes, and it has the definite advantage, as was noted,
that "it gives the outline of a reasonable and objective procedure for
pulling them [plans] out of code. " But it's quite a limited model; it
certainly doesn't describe everything we know about programs in general or a
given program in particular. It's not influenced by the task, it doesn't
contain elements of spatial imagery, and so on. (That's not a criticism.
Rist did a very impressive job. He didn't set out to cover those aspects.)

The bottom line, I'm afraid, is that if the 'authoritative statement' that
has been looked for means, something cut and dried and applicable to all
conditions and the same for everybody etc, then it's going to be a very
bland, weak statement. At least until cog psych has got a bit further.

However, we can say more about what the mental representations might be.
Andrew wrote ...
> or did
> I miss the experiments that tested alternate definitions of programming
> plans to see which definition best matched the internal representations
> of experts?

Can I refer you to a very interesting paper by Pablo Romero, in IJHCSm2001
54 211-236, called 'Focal structures and information types in Prolog'? I
will summarise it, but please be aware that I haven't yet read the paper
closely and I may be missing things. Also, if this is old hat to everyone,
please excuse me and skip the rest.

Romero considered several suggestions of what might be a focal structure (I
like his choice of term): Plans (Rist's definition), data structure schemas,
Prolog 'techniques' (Bowles and Brna, 1993) and recursion points. In his
Expt I, he applied these to each of 3 (rather small) programs and for each
type of focal structure, he divided the programs into key segments and
non-key segments. Then he showed the programs to programmers (3 levels of
experience, see below) and asked them to understand and memorize the
programs. (I am simplifying his procedure.) Then asked them to recall the
programs.

The theory here is that, whatever structure experts use, they will apply
that structure to the program they're given and see it in those terms. They
will then recall those segments of the program that are key segments, wrt to
that structure,  much better than they recall non-key segments.

Non-programmers, in contrast, will be expected to recall key and non-key
segments about equally. Novice Prolog programmers will show an intermediate
effect, surprise. 

What he found was that the data structure schemas showed a strong
differentiation between experts and everyone else, whereas none of the other
three structural models showed a strong difference. To my eye, the data look
quite impressive.

The 3 levels of experience were: experts had on average 8.6 years of Prolog
experience; novice programmers had a 3-month introductory course;
non-programmers "did not know anything about computer programming".

His Expt II used a recognition task instead of a recall task which I'm not
going to summarise, at least not right now.

Romero carefully reports his results: "The global results of the study
indicate that data structure schemas are a plausible model of structural
knowledge for Prolog, but functional information, and Plans, are important
as well for Prolog programmers. This result does not rule out the
possibility that there might be further aspects of the code that are
important for this programming language." (p. 234)

It is not at all surprising that a single model is not sufficient. The
Gilmore and Green paper likewise found that neither the Plans model alone
nor control-flow knowledge alone was sufficient to explain our results. That
is part of what I was saying above about mental representations being labile
and influenced by the task.

- And where in all this does the 'situation model' come? Perhaps that is one
of the more interesting senses of 'understanding a program'.

Thomas

----
T. R. G. Green                    also at:
preferred postal address:           Computer-Based Learning Unit
Oriel House, 27 Allerton Park,      University of Leeds
Leeds LS7 4ND, U.K.                 Leeds LS2 9JT, U.K.

0113-226-6687 (tel)
0113-226-2751 (fax)
http://www.ndirect.co.uk/~thomas.green




- 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]

Reply via email to