One of the reasons why 'scientific' programming research is so difficult
lies in the fact that in many cases there are so many different extraneous
variables to control. Programmers, as do programs, vary greatly - the
background and experience of the programmer, how old the program is, how
many times it has been modified etc. all can sucessfully hide any phenomemon
you're trying to study. You can try to remove as many as these variables as
you can, but that could take you away from the initial problem that you're
studying. One of the criticisms that Sheil came up with (and justifiably
so), was that of the validity of the experiments that he described - some
were very removed from the 'real-world' of the programmer. Creating an
artificial setting is all very well and good, but it is a significant
distance away from the real programmer. It is very easy to criticise both
approaches, and Sheil does this very well.
Your question of programming style is exactly the same one that lead me
towards PPIG. What should we do about function size, indentation and
indentation level, identifiers, and identifier length? Issues like domain
distinctly affect programming stylistics, and how the language is applied to
solve a specific problem. Teasing out one effects of factors from 'real'
code _is_ difficult, time consuming and expensive, although in a couple of
cases, work has been done.
Complementing the 'scientific' study of programming is the 'engineering'
approach - tool and environment design - supporting environments for the
programmer. Building something and seeing if it works and what benefits may
be provided may give rise to more rigorous analysis. Analysing comparative
progamming styles may be possible, but incredibly difficult from an
engineering perspective - again, domains vary in complexity, as do
programmers. A particular development problem, as I'm sure you will agree,
can overwhealm any the advantages that a particular style may provide. In
our development department, as long as there is agreement to style, then
things are fine - it being a recognised programming 'dialect' used to make
explicit issues that may have been immediately visible.
No, I don't think cognitive psychology should be ignored. Limited
short-term memory and inability to accurately process negative conditions is
something that every programmer has to deal with. It has role to play, but
to the engineer who has to produce products and working systems, one has to
be pragmatic.
> So where are we today, 20 years later?
There are a few more programming forms to 'play' with. More tools, visual
languages, object-orientation, and methodologies. I would like to hear
other PPIG'ers views on this (and language styles)!
Kind regards,
Chris Douce
Software Developer
www.fbk.com
