How do we count programmers? A while back on this group a wager was
described based upon predicting the proportion end user programmers (at
some future date). I'd like to muddy the waters by asking how does one
recognise a programmer? If we look at the population of notation (and
tool) users it is interesting to consider what it takes for a notation
user to be counted as a programmer. There are numerous criteria that could
be adopted based upon prescribing a range of behaviours of some general
machine in terms that can be mechanically interpreted. Two interesting
aspects of this problem are:
* notations (and tools) that are not presented as programming languages
per se but which exercise the user's mental processes in much the
same way.
* notations (and tools) that are never `run' but, in principle, are
treated as though they are mechanically interpreted.
A common illustration of the first of these is HTML and its extensions for
designing web-sites and controlling browser behaviour. HTML extensions
include tags, forms and tables with conditional meanings as does the
treatment of HTML-frames. In addition notation users frequently engage in
trying-out and de-bugging their web pages (see note in PPIG newsletter
???). The question as to whether contemporary HTML is as powerful as
a programming language is hard to answer, however I would suggest that
HTML authors potentially engage in mental activities very close to those
of programmers. Clearly HTML authors may not think that what they are
doing is programming, but I think it is possible to interpret it as
programming. So if we are interested in the psychology of programmers
should we include the psychology of HTML authors?
A less common illustration of the second of these is the many academics
that engage in formal specification. Here, they are developing,
manipulating and modifying formal languages that may never be run
--- however specifications are treated as being able to denote the
behaviour(s) and states of running systems. In addition, there is no
question that specification languages are as powerful as programming
languages. Again, I would suggest that specification authors engage in
mental activities very close to those of programmers. So should we also
be interested in the psychology of specification authors?
These are two examples are designed to push the boundaries of PPIG work
and interests. By similar arguments other activities could be looked
at as feeding and benefiting from PPIG work. For example, what about
requirements specification, planning, etc.? From a psychological
perspective any sufficiently powerful domain should be of interest
and relevance. And, from a programming perspective conventions or
lessons learnt within other domains may benefit approaches to program
design. Perhaps in the future we may have users who think they are
designing web sites and don't know that they are really programming.
Thoughts, feedback, etc. welcome.
Chris
--
------------------------------------------
Chris Roast
School of Computing and Management Sciences
Sheffield Hallam University
Sheffield, S1 1WB, UK
------------------------------------------
Tel. +44 (0)114-225-5555 (switchboard)
Fax. +44 (0)114-225-3161
Email. [EMAIL PROTECTED]
------------------------------------------
http://homepages.shu.ac.uk/%7Ecmscrr
==========================================
