> If by "understanding a program" one means holding the entire representation in
>internal memory (short or long) at once, then I concede that one can never understand
>a program; by similar reasoning, one can never understand history, medicine, or
>psychology either. The use of some kind of external representation is essential to
>understanding programs.
But isn't this the whole point of abstraction. By creation of sub-constructs they can
be given a label and reasoned about as a whole. If a programming language supports
abstraction constructs that are congruent with the way in which people reason about
the program then the programming language supports reasoning and it is more likely
that a single individual can
understand the whole program.
Actually, it is better if the programming language supports the constructs but not
essential. If proper programming idioms are used then the abstraction is an emergent
property and can be given an implicit label which still supports reasoning about the
program as a whole.
A personal example that is highly current. Over the last few months I have written a
translator (not a compiler but...) and am currently training a person to take over the
maintenance of the program. It is written in flex/bison/C++ so the lexical analysis
is handled using regular expression in a flex script, the parsing is handled by a
bison (aka yacc) grammar
and the parse tree is a binary tree of nodes (C++ class instances) with all
optimization and code generation handled by Visitors on the parse tree.
To anyone who knows the language of design patterns this succinctly describes the
architecture of the program so that looking at any component allows that component to
be placed within the context of the architecture and more easily understood. The
whole point of software architectures (aka architectural patterns) is to support whole
program comprehension.
Perhaps, patterns (design and architecture) are an external representation in the way
you are thinking?
> It is probably also the case that programmers never understand even moderate sized
>programs entirely, even using an external representation, unless they are required to
>do so by a laboratory experiment. For many real-world tasks, they can, in fact, get
>by with a trivial, local understand of the code, just as it is unnecessary for a
>physician to use knowledge of
> the biochemistry of microorganisms to decide to what to prescribe when you show up
>with the
> symptoms of the flu that's been going around.
I think there is a deep issue here. Based on the idea that layers of abstraction
allowed people to work with system without understanding lower layers, the computer
science community separated analysis from design from coding. It is now being
recognized that this was a Big Error. It is now clear that people cannot design good
systems unless they can program
well. Moreover, people cannot architect good systems unless they can both program
well and design good systems. OK so architecting and design have a very blurred
boundary. Indeed so does programming since all three "skills" are generally required
to do a good job of constructing any good computer-based system.
In effect good systems development requires an holistic approach.
Relating this to the medical example, a good physician prescribing a drug usually has
at least a superficial understanding of the microbiology at work (microbiologists may
disagree with this of course -- indeed one I know definitely thinks so but..). Bad
physicians do not think about the holistic situation and give people new problems in
trying to cure them of
obvious problems -- most instances of candida infestation are caused by bad
prescribing of antibiotics.
So programming is not the only situation where using only local knowlege is a bad
thing. I would say that a professional program maintainer MUST obtain more that a
trivial local understanding of code before making changes. Reasoning about the knock
on consequences of change, or at least trying to clearly bound the area of possible
effect of the change is
crucially important. I guess this is why we have so many bad practitioners and so
many badly maintained programs.
> Neither of these points are relevant to the issue of whether programming requires
>knowledge of
> global schemas/plans or whether they can just get by with very local transformation
>rules.
> I think the lack of success in constructing "automatic programming" systems and the
>large role
> that skill and experience play in programmer performance are strong arguments for
>the deeper knowledge.
Or at least a deeper ability to reason about non-local consequences that a good
undestanding of the program as a whole brings.
Russel.
======================================================================
Professor Russel Winder Professor of Computing Science
Department of Computer Science Fax: +44 20 7848 2851/+44 20 7848 2913
King's College London [EMAIL PROTECTED]
Strand, London WC2R 2LS, UK http://www.dcs.kcl.ac.uk/staff/russel/
- 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]
