Abstract 1
1. Introduction 1
2. Incentives 2
3. Obstacles 3
4. Desiderata 4
5. Generalities 6
6. Key points in the procedure 7
6.1 Introductory
remarks 7
6.2 Basic concepts
of process 7
6.3 Concepts of
data and data manipulation 8
7. Class timetable 9
8. Parthian shot 10
References 10
Abstract
Even if you’re on the right track, you’ll
get run over if you just sit there.
Will Rogers
Structured program design is a rewarding vehicle for the introduction
of problem solution and computer concepts to age groups ranging from mid
primary school to senior management. Progressively expanded subsets of the
material form natural units after each of which the student may continue to
more advanced levels, or stop with a logically coherent grasp of the subject so
far. The intellectual and practical value of the concepts are emphasised,
together with the speed with which they can be instilled. Material requirements
and training aims are illustrated with an outlined instructional procedure.
1. Introduction
If it's stupid but it works, it aint stupid
Anonymous
After sociology, psychology, and economics, there are few fields of
endeavour that spawn so much philosophical dissension as education. More than
most contentious subjects, its product is both real and of crucial importance,
but the scope for argument is varied and vast. Firstly, few practitioners of
most subjects will agree on the best technical practice; few administrators
agree on the selection of subjects or subject matter; few teachers agree on the
best teaching techniques for a given subject; and no-one seems to agree on how
to assess the results of the teaching. It has been quoted [1] that if computers
had existed in the Middle Ages, programmers would have been burnt at the stake
by other programmers for heresy. Teachers did burn other teachers at stake in
those days, but the practice has largely been discontinued, to the apparent
discontent of a large minority of the profession.
In view of this modern exemption from too-literal contribution to
public illumination, I herein honour the venerable tradition of amateur
contribution to the subject (if not necessarily to its advance). Not all the
following opinions and observations are revolutionary and none are contaminated
by excessive attention to the theory of didactics; their justification relies
on good intentions, strong views on the merits of the subject matter and varied
experience in its teaching and application. Those are no guarantee of
soundness, but might serve to confuse hecklers. What I most dramatically lack
is any pretence to controlled studies or other requirements for academic rigour
— not out of disrespect for such, but simply for lack of the opportunity or
incentive for the necessary investment of resources. You are invited to
consider without prejudice, the plausibility of the views and the promising
empirical observations, as grounds for formal investigation or practical
application.
It is perhaps a bad sign that I shy away from too tight a definition of
one of the key words in the title. Computer literacy — or computeracy, as I
prefer to call it in analogy to numeracy — is a term that people airily apply
to a number of concepts, ranging from confidence in use of a terminal without
any idea of what is going on behind it, to a sophisticated appreciation of a
wide range of technical topics.
Various parties invoke vague definitions of the term “computeracy”,
based on various levels and assorted criteria of competence. In appropriate
contexts, insight into hardware might be one topic, and, at more superficial
levels, knowledge of computer languages and data representation. As I see it
however, the ability to generate, or at least follow, an algorithm in some
familiar notation, is arguably fundamental. At the next level we might rank an
ability to apply certain disciplines to the generation of algorithms to solve a
reasonable range of classes of problems and to grasp in principle how more
advanced problems might be approached. Expression of algorithms in a
programming language, plus appreciation of details of the implementation may
follow, by which time we decidedly encroach on the territory of programmers, or
at least coders.
Such simple computeracy need not in principle be a sound basis for
further study, but a student with the will and aptitude should be well placed
to continue from any point in the process that I describe here. If my
recommendations should yield material and intellectual benefit, I would be
gratified.
2. Incentives
If you think education is expensive, wait
till you have tried ignorance.
Various sources. Possibly starting with John Lubbock
Like almost every practitioner of any subject, I regard mine as being
of special educational value and philosophical significance, and my
justification is not simply the growing importance of computers in the modern
world. The generation and manipulation of abstract algorithms seems to me so
fundamental a skill for minds that have the aptitude, that their undoubtedly
mundane value is of secondary interest. Their intellectual value I see as
rivalling pure mathematics or any applied science, and, as a skill in problem
solving, of practical value close to that of the three R's.
So much for the first exhibit.
The next point is that program design is teachable, at least to
the calibre of pupil likely to select it as a subject. Teaching, no less than
politics, is the art of the possible and it would be criminal to permit
computer-related skills to be passed over on the grounds of intrinsic
unteachability. In fact, in the subject of algorithmic skills, it seems to me
that the main differences between teaching children and teaching adults arise
on the one hand from the adults' greater repertoire of familiar skills, and
their perspective on problems and requirements arising from their wider
experience. This eases the assimilation of certain classes of new skills and
gives the instructor more scope in the selection of examples and exercises. At
the same time however, it simply might harden their preconceptions, leaving
them with more to unlearn, with overconfidence, or with defeatism, in any
combination.
On the other hand, children have their own strengths: greater
receptiveness to, and retention of, new concepts and procedures as long as
they are given the necessary background knowledge at each stage of the learning,
and as long as they can immediately apply each point as they learn it.
These provisos make certain demands of the instructor in the construction of
examples and exercises, but need not be severely restrictive. Also, perhaps
because the children I have been in contact with have tended to be bright, they
have shown themselves able to cope with abstraction rather better than
most naively incomputerate adults.
To me the two most exciting things about the approach that I favour,
are firstly that: except in detail, the approach is equally valid for any age
group, from post-toddler to sub-decrepit, and secondly that: unlike most
syllabuses, it is more or less independent of the pupil’s pre-existing levels
of knowledge outside the field. Sometimes, for students entering the course in
the context of previous training, even a fair amount of unlearning may be in
order (say: learning how to do without gotos; or: when to avoid bottom-up
thinking...).
However, in beginning with abstract structured design and justifying
the process by demonstrating examples of the fruits of the principle on the
computer, one can quickly supply the basic concepts and confidence required for
the superficial student on the one hand, while on the other laying the
groundwork for any future level of algorithm, data, or procedure design
required by the future professional.
The conceptual structure is generalised, and the smallness of the
kernel of understanding it requires, should have as much impact on the ease of
teaching teachers as on teaching students. Actually, in the right circumstances
any keen student is likely to achieve more in the application of computers than
one might predict from his rated academic level, if the work of such as Papert
[2] is anything to go by. What the application of computer facilities does for
computer literacy, is a subject in itself, but apt students are likely to apply
structured thinking to external problems solving as well.
Note that this essay is no diatribe against bottom-up work; anyone who regards bottom-up design as undesirable on principle, or against designs that are not based on procedural programming or linear logic, has a long way to go in computer theory and practice, but such considerations are not relevant at the point of program design relevant at this point in the student's education.
3. Obstacles
Better to understand a little than to
misunderstand a lot
Anonymous
Perhaps because of its youth, computer/information science is rarely
taught with any great technical competence in schools outside the field of
Information Technology. All the best practitioners are too busy earning a
living and sneering at the products of the educational institutions, to
contribute much to solving the educational problems. Teachers still tend to
lack the in-depth experience necessary to appreciate the merits of those
disciplines that have been shown to contribute to sound practice. (“Don’t waste
your time on all that fancy indentation, comments, and variable names; get on
with the job!!!”)
Also, unexpectedly in view of the simplification introduced by the more
popular of current techniques, it seems to demand of teachers that they master
in advance, a surprisingly sophisticated grasp of the principles, if they are
to impart them with conviction.
None the less, the simplicity of top-down design in the form of
structured programming is there, and enables one to produce in a short time and
without tears, students who are house-trained and have a sound basis for
further development.
Frustrations that beset anyone with views consistent with those I now
detail, include the combination of the obscene incompetence of design of
language and support systems foisted on the market by the dominant vendors,
with the smug idiocy of practitioners who see their ability to "get on
with the job" irrespective of quality of the tools, as a merit of those
tools. This spurious merit in application they then tout as merit in education.
Sometimes they see it as not mattering at all, and sometimes as a positive
virtue that the beginner be given a taste of things to come.
Others point out with perfect truth that it is a bad language indeed
that cannot be used in a style that conforms to the spirit of good structure
and useful notation. That such expedients are aesthetically offensive may be an
over-fastidious view, but they undoubtedly are severe sources of noise in the
instruction of beginners.
The arguments that it is easy to be wise in
hindsight, and that a vendor without his own version of BASIC together with his
own horrible extensions will go to the wall, hold no water. The hindsight has
been accessible to all for decades, but the unifying feature of almost every
BASIC to come on the market, is the ingenuity with which their language
extensions ape each other without achieving compatibility, generality,
elegance, or even usability. The stench of ad hockery is pervasive and it is
hard to believe that we have anything but the whims of systems programmers to
thank for the motley collections of rarely-used instructions that clutter the
manuals. The largely counter-productive obsession of vendors with locking-in
their customers, seems to inhibit their support of the recognised structures.
This conflicts with the stated justification of say, Java or a structured
dialect of BASIC as the universal language.
Like several other popular languages, these have their respective
merits, but they have a nasty way of setting the minds of naïve pupils like
concrete, with a resistance to the idea that there is anything more fundamental
to programming or to computers, than the programming notation that they have
become comfortable with.
If that is as far as it goes, then very well, but otherwise, one has to
grapple with wistful thoughts of teaching the students machine language. That
would be desirable for students of computer science, but might be a doubtful
kindness to naïve users.
The design of languages and extensions by the academic community has
not been free of acrimony or monstrosity, but, individually, their most
prominent prospects for general introduction have all been usable. Meanwhile,
the main difficulty in supplying students with sound tools to exploit the
exciting equipment now available, is that most of the cheapest and most attractive
systems either support none of the acceptable notations, or do so unacceptably
clumsily, or as very expensive options. This perpetuates the situation as a
sort of technological-commercial blackmail. The simple production of better
tools may be feasible for the individual user, but the effort is sizeable even
if he is equipped for the task; the delay in implementation of the teaching
project is often prohibitive; and the fact that he is then saddled with the
maintenance of an incompatible package on an obsolescent system is a powerful
disincentive to independent action.
This does not prevent sound education, but it severely inhibits it,
increases the expense and persistently introduces contamination from proponents
of the quick-and-dirty. In theory the recommendations of this essay are
notation-independent, but students typically wish to get down to business after
mastering a notation, so it commonly is more desirable to select a language
that is available on the system that is likely to support the programming
environment in question, rather than to choose a language on the grounds of
intellectual excellence.
Depending on the intended objective of the class, one need not use
simple procedural languages at all; for example, one could use specialist or
application-oriented languages such as spreadsheets, or scripting languages
such as AWK, Javascript, or Python.
4. Desiderata
Notation is a tool of thought.
Kenneth Iverson
What would be the features that I would specify in a system to suit the
teaching methods I recommend? Actually the requirements are rather simple and
even loose. Personally, as a practitioner predominantly of functional
decomposition using pseudocode, I want a target language that is itself usable
as pseudocode with minimal modification of syntax, and with a convenient
comment facility.
In particular, violation of functional structure in translation to the
target language is undesirable. It also is a nuisance if the language or its interpreter
or translator requires too cumbersome a superstructure of declaratives.
Declaratives are tolerable at worst, but it makes life easier if they can be
neat and, in concept and format, compatible with the procedural text.
Declaratives tend to strike students as mystifying, cumbersome, and irrelevant
to the concepts embodied in their code. It also is nice if it is convenient to
omit declaratives from the students' first efforts, or at worst, to invoke them
automatically from a standard library or some other automatic source.
Unusually among evangelists, I do not necessarily consign other
notations and methods to outer darkness, but do insist that the road to
salvation lies through the ability to handle abstraction at varying
levels, both bottom up and top down, without violation of structured
programming basics.
As far as may be practical, support systems should be user-friendly,
but can be obscure if that is the price of brevity and convenience. It is less
disruptive to be told, first to enter a string of say two letters, a delimiter
and carriage return when you start, and then enter a similar but different
string to run, and another variant or two to stop etc, than to understand the
helpful technical terms that appear, variously mangled, in many
commercially-oriented command languages.
Of course, since the days in which I originally wrote that, command
languages have largely fallen away, but the principle remains valid, and is
badly violated in many GUI designs.
A natural language command handler sounds nice in theory, but most
implementers seem to think that they achieve such a facility by using long
English words for mnemonics, arbitrarily selected, often partly abbreviated and
with rigid American spelling.
In practice I find that most naïve users seem happier with few, short
commands, even if they do not understand the mnemonics, as long as access to a
menu or list is instant and convenient. It also is important that the
circumstances for the use of each is easily described and recognised. Children
in particular take to this like ducks to water; in fact, they sometimes revel
in esoteric terms, apparently relishing them as "in" words.
They also like single-stroke function and abbreviation keys and complain (but
quickly adapt) when new systems lack features that they are accustomed to.
Another attractive approach is for a system to accept full English words but to
require only enough letters to avoid ambiguity in context.
Again, since I originally wrote that, the need for caution with naïve
auto-completion has become painfully obvious.
Minimisation of keystrokes and of independent concepts appear to be key
factors in achieving the kind of user friendliness that appeals to the budding
computer initiate. A more worthwhile attribute than a misleading resemblance to
English is that the work required to identify and specify an action is slight,
and that disaster does not lurk in a thoughtless keystroke. It should not be
possible, without elaborate idiocy, to destroy the system or the last session's
work, or even find oneself bootstrapped out of the current game.
Automatic saving of one's status at strategic points is also nice if
available.
It is more important to ensure fast and convenient response and job
submission, than to use English commands. This makes interactive facilities
attractive and local intelligence preferable to remote computer processors.
Local time sharing with several access points connected to a processor in the
same room is all right, as it not only cuts out the communications
unreliability, but helps pupils recognise the consequences of sharing. In
particular, if the system goes down, all can swear or groan together, without
the bitterness, frustration and confusion of wondering whether the remote
terminal has gone glassy-eyed because of one's own fault, line-, terminal-,
processor-, software-, or systems programmer- fault.
Again, pupils nowadays tend to have their individual personal computers
online, so it is easier than it used to be, to avoid such annoyances.
In fact if need be, the committed pupil will accept monthly
response by runner with cleft stick, but as a rule such delays take the fun out
of things.
No fun — no learn.
Still, although the modern child is too blasé to appreciate systems
that would have been regarded as miraculous even a generation ago, one can run
a successful course with unimpressive resources.
In summary, happiness in a school environment would be a system of
personal computers, probably connected, possibly with a few screens each,
supporting at least one suitable language, say Modula 2, Python, or Java,
preferably in both interactive and compiled versions, and with a variety of I/O
devices, including modest-resolution interactive graphics and high resolution
hard-copy graphics. Data storage preferably should not be restricted in speed
or volume.
For courses for students who need to achieve more advanced programming
insights, it would be highly desirable for them to be able to inspect the
lower-level code generated by their compilers.
It is important to get the requirements into perspective. One cannot
expect to get the best results in strongly unfavourable conditions. In
particular, if the students cannot get at some facilities to see the results of
their efforts, it would be naïve to expect most of them to maintain much
enthusiasm. At the same time, the methods outlined here do not compare
unfavourably with any others under matching restrictions. Much can be done with
chalk when computer access is in short supply. The compromises that one then
must make may be disappointing, but need not be disastrous.
5. Generalities
If you don't
know how to do something, you don't know how to do it with a computer
Anonymous
There are many valid routes to a working knowledge of computer related
matters. Like most practitioners of my generation, I began on second-generation
machines in low-level languages and developed from there. That suited me, and
my only regret is that structured concepts were not in general currency in
those days. For years my prescription for the beginner was to begin at the low
level and build on the sound foundation thus provided. Since then several
things have happened to reduce the general applicability of that advice.
For one thing, it now is commonplace to require a non-trivial
understanding of matters concerning computers, even for staff who are not in the
IT industry as user or vendor etc. Secondly, it now is the rule rather
than the exception, to use high level interfaces only. An amazing number of
commercial programmers nowadays do not even know what a low level language is.
That thought is somehow disgusting, but the material grounds for objection are
few — and shrinking.
Now, apart from the question of the academic soundness of the
run-of-the-mill practitioner and the emergence of users peripherally associated
with IT, another class of educational requirement has emerged. Children started
the invasion as scattered secondary-school students, but they now bid fair to
become the major consumers of all computer-related education.
What is more, it now seems to me that their computer education should
overlap the three R's and precede sexual instruction. If so, then there are at
least two factors invalidating the low-level to high-level route as a fixed
policy. Firstly, the intellectual relevance of the technical low-level
information is far lower. In fact, pre-computer concepts need not suggest
computers at all; they could deal with the likes of algorithmic concepts such
as dictionary or directory searches, or critical path planning in making a
meal. Computing toys that demonstrate mechanical arithmetic, such as abacus,
finger calculation, mechanical adding machines with visible works, even slide
rules, would work — for interested pupils.
Secondly, while some of that type of material is easily assimilable and
even interesting to some children, it is a large subject and few would have an
appetite for enough to constitute a course, even if it were of enough practical
relevance or urgency to justify the investment in school facilities.
On the other hand, the basics of program design as an abstract
subject can nowadays be imparted in a few hours of classroom time and if
suitable computer facilities are available, can yield pleasing and rapid
concrete results; it forms the foundation of a subject wide in its own range,
rich in intellectual content and of value as a mental skill and practical tool
in many other subjects.
Such a combination of teachability and teach-worthiness should surely
be the educator's dream. The youngest children I have tried it on were six
years old. To the limits of their arithmetic abilities, they did rather well at
it. Eight-year-olds were easier to deal with, but I should hesitate to
undertake to teach it on a routine formal basis to such an age group. Keen,
bright ten-year-olds are no problem.
One must of course distinguish between instruction of individuals and
teaching in the classroom situation. It is hard to see how one could go about
teaching a mixed-ability class of fair size and varied motivational level, but
as an elective subject, it is a beauty. Of course, other approaches enable one
to impart non-trivial computer skills to even younger children. Most
prominently perhaps, Papert [2] has impressively demonstrated the development
of both programming and debugging in his pupils. He argues that both are skills
of many unexpected intellectual benefits and that each is worthy of recognition
in its own right.
I have no fault to find with these views, but think that it will be
some time before we can apply them on a large scale. Also, the subject matter I
recommend is for the most part more rigidly structured — more of a
discipline. This is not to denigrate un-straight-jacketed education, or even to
deny its legitimate place alongside formal material in the same subject, but
for the age groups in question the formal material is accessible and can yield
rapid, predictable results. Besides, taught as a discipline, these skills are
more easily applicable to recognisable cases and the procedures are more
calculated to avoid wasteful false starts: these are features attractive in
budgeting curriculum time. There is no conflict between the approaches; they
are compatible in concept and in practice. In fact a fair percentage of the
material I prefer to present in an exploratory fashion, using the computer as a
tool; and preferably a visual, interactive tool.
6. Key points in the procedure
The exact approach and
sequence may vary according to taste and especially according to the facilities
available. The following text assumes a rather generously equipped class, with
at least one interactive screen per small group.
6.1 Introductory remarks
He had bought
a large map representing the sea,
Without the least vestige of land:
And the crew were much pleased when they found it to be
A map they could all understand
Charles Dodgson
There is not much special about this. The usual considerations apply
for establishing rapport, requirements, expectations etc. It is perhaps more
important than usual to put the class at ease and to ensure that there is no
reluctance to ask questions; the process is futile if not participative.
6.2 Basic concepts of process
Education is the process of moving from
cocksure ignorance to thoughtful uncertainty
Anonymous
At the start the best way to illustrate process is to
demonstrate a very simple program text in an interactive interpretive language,
very transparently written with descriptive vernacular variable names and
including NO COMMENTS. Comments are apt to be taken for part of the
functional code. There is plenty of time to introduce comments a little
later — at this point they are so much noise. Whatever examples are shown
should be impeccably structured and religiously adherent to good algorithmic
practice — pre-reading before loops and all that.
BUT this
is not the time to point it out to the innocents; let them simply think that
this is the way one does it. Do not evade pointed questions, but even then, do
not elaborate. Simply explain that violations of taboos cause hair to grow on
the palms and that all will be explained anon — and do not forget to explain
it anon!
To illustrate: a good starter is something like a counting program that
chattily prompts for a digit of input, then prints that many numbers from one
up in sequence. Let the students satisfy themselves as to the range of function
of the program — usually a minute for adolescents and up, but tots will
sometimes raise the roof if interrupted too soon.
Be that as it may, before boredom threatens, but after the first flush
of enthusiasm, one shows them how to list the program, then takes them reading
step by step through it, not explaining anything unless absolutely essential
for immediate understanding.
The purpose at this point is to associate each statement with what was
seen on the screen, emphasising the sequence of events and changes of value. As
soon as this has been done, however sketchily, encourage the students to
experiment — first with modifications to the text, say changing prompts,
annotation literals and count constants or whatever is convenient and
illustrative, then with changes to statement sequence and duplication or
omission of statements; and lastly with enhancements, such as putting the whole
code into a loop so that it repeats the whole rigmarole after each performance.
A cardinal danger is the temptation to explain too
much. Rather let them
experiment hands-on to see what happens. There are dozens of things one can
explain, such as the significance of the commands to run the program or editing
functions, or the syntactical rules of the language, but now is not the time.
What seems to work perfectly well without confusion, jeopardy of future subject
matter, or student dissatisfaction, is simply to say that one does so-and-so at
this point to do such-and-such. Only if importuned, promise that all will be
revealed in good time, but that at the moment we want to carry on.
It is amazing how many foundations for further conceptual development
are laid at this point, but it is also now that one first encounters the fact
that only the exceptional student has done more. All one can rely on is receptivity
for the next stage, and even that evaporates if not quickly
reinforced, preferably by another and slightly more advanced program example.
One I have used with success prompts for a number and moves an asterisk across
the screen that many times. It then repeats the process until an end of job
condition is encountered. This introduces string handling through changing the
asterisk's "tracks" and various other whims.
About now is a good time to consolidate what has been achieved by
identifying and naming the key concepts, so back to class. The first thing I
do at this point, is to teach the Dijkstra structures. The notation I used
to illustrate the process flow is old-fashioned flow-charting, using only the
rectangular process block and the diamond-shaped decision block. Obviously the
choice of notation is not critical, as it is the only exposure to flowcharting
that they get from me, All that matters is that it must be very simple
and very visual and shows procedural flow.
The point of using flowcharts at this stage is that what is being
illustrated is just that: FLOW; the flow of control in the sequence, selection
and iteration blocks. This flow is not explicit in the notation of the typical
block-structured language and explanation that the bottom of a loop means that
execution continues from the top until termination, is at first troublesome to
many students. Starting from the sequence construct also permits flowcharts to
dramatise the occurrence of such components in loops and selections; the nature
of each construct: once into the block, all the way through, and once
out; and the consequent naturalness of nesting blocks of anonymous
content to indefinite depth.
As the concepts are simple and easily memorised, flowcharts are not
needed afterwards. Once the block structured notation is understood, the class
is generally perfectly happy to use it, suitably indented, as program code and
documentation, as indented code is as visual, less trouble to code, and
directly compatible with the available I/O media. I have yet to hear a
pupil complain on being told that flowcharts are from now on to be ignored in
class, though they are free to draw them for their own purposes if they choose.
Incidentally, one of the few items of nomenclature that I insist on
having memorised, is the sequence-selection-iteration triplet. Terminology can
be a vast help to fixing and accessing concepts in perspective, and this is one
case where it works miracles. Throughout the discussion, there is continual
reference to the code they have run, to identify rather than merely recognise
the structures they are learning. Further examples of very small illustrative
segments of code can be elicited in this phase of the class. How much more
machine time is to be consumed in the process depends on available facilities
and on requirements. The problem of termination of loops due to circumstances
arising halfway through their code is ideally dealt with by demonstrating the
venerable nested-if-and-flag-variable technique. Having used it till the problem
and the structure are ingrained, one can graduate to the loop exit statement
and stay with it, as long as the available software supports it.
At this stage, the goto remains a nono, not in deference to any dogma, but because it invalidates the assumptions on which structured programming is based, in particular that blocks are nested, and that each block has precisely one point of entry and one exit. Violation of such assumptions interferes with program design, debugging, proof, subroutine assignment, and re-use of code.
6.3 Concepts of data and data manipulation
The only books
that influence us are those for which we are ready, and which have
gone a little farther down our particular path than we have yet got ourselves.
E. M. Forster
So far the concept of data has probably been treated very casually.
Perhaps the instructor has even managed to avoid talking of constants and
variables, or if not, to sidestep the question of storage. Notice that
everything has been very abstract and none the worse for it. The primary reason
for leaving things out so far, has been. that there is so much to tell, but
there is an interesting by-product. Because everything has been structured in
coherent modules of concepts, one can let students drop out of the course as
soon as they have mastered all that they need, at any of the frequent points
when a subject has been buttoned up for the moment. What individuals never ask
is largely what they never need if advanced study is not the requirement.
However, this is about as far as it is comfortable to go without
considering the nature of data in greater depth.
The first thing is to tell as much as is necessary about the nature of
data storage in the machine. The approach depends very little on the background
of the class. Even if they know about such things, binary, floating point and
the like are not at moment of the essence. The main points are that the storage
is finite and that the entities are pigeon-hole-like and can be labelled and
accessed as either constants or variables. This need hardly be illustrated with
new code, as the examples used so far are ample.
The assignment statement merits explicit attention at this stage, in
combination with expressions. Using the pigeon-hole illustration, one can
easily show the sequence of operations needed to achieve the effects observed
in the running of the programs, including temporary storage locations etc. Here
one also can deal with the hierarchy of operators. At points like this one can
generally carry on at a moderate speed with advanced ten-year-olds, but the
younger children often have too little background. They can pick it up very
quickly in this context, but that is hardly the primary object of the class.
Partly for this reason and partly for fear of clashing with the educational
authorities, it may be better to limit oneself to very simple expressions.
Now comes a major step: the introduction of subscripting. It is not
difficult to illustrate, pigeon-hole style, but it is the key to the next set
of live examples. The important points are the array membership name,
the use of arbitrary expressions as subscripts and the possibility of an
arbitrary number of dimensions. Suitable subjects for illustrative programs are
sorts, searches, and two-dimensional placing of characters on the screen.
Incidentally, this also makes for a very easy introduction to graphs and functions.
By this time it would labour the point if I were to detail the steps.
Suffice to say that more sophisticated data concepts such as pointers, and structures such as lists, stacks,
trees, and types, derive easily from the same process. The functional decomposition
approach developed accommodates the generation and modularisation of code
naturally and the sky is now the limit. No common school of disciplined
development is excluded, data flow, data entity, functional, the lot. With a
little trouble one could probably explain what a go to is, though explaining
why one might want to use it could present problems.
Consider the following real life example: I was teaching a mixed class
the basics in PC BASIC, and had shown them arrays. I set them the problem of
displaying increasing powers of two on the screen. Then I let them continue
until they got a numeric overflow condition.
Understandably they were stumped and did not understand the problem. I
explained the difference between formal mathematical numbers and the limited
physical storage items in a computer, and I cannot remember whether mentioned
the concept of adding more storage to accommodate larger number. We were about
to proceed with the class when one of the younger class members, perhaps aged
twelve, erupted: “I can see how to do it!” and explained his conception of
multiple precision. I praised him and tried to proceed, but he insisted that it
would only take him a couple of minutes, so I capitulated and he did indeed
write a program that we then left running and filling the screen with ever
larger powers of two while the class continued.
He was a remarkably precocious but unassuming little lad, and I often
wonder about his career thereafter.
Anyway, it illustrates the effectiveness of the principle of letting
the class learn by building sophisticated structures on elementary concepts.
That is to my mind one of the fundamental objectives of the approach. But do
not rely on such moments if there are no gifted and interested class members.
They are occasional and special treats.
7. Class timetable
The only books that influence us are those
for which we are ready, and which have
gone a little farther down our particular path than we have yet got ourselves.
E. M. Forster
Of course, the speed of progress of such approaches will vary with
circumstances, but I hope it is clear that by any standards the rate can be
very rapid. Unnecessary delay at the start will cause greater frustration than
having to go back and clarify confusion. I have seen curricula in which the
Dijkstra structures are introduced on separate days. That is disastrous: much
like trying to teach walking with the left foot on the first day, and walking
with the right foot on the next, then the hop, then walking with alternate
feet.
Really advanced concepts become accessible within a day or so of class
time if the facilities are available. If what was once regarded as essential
background is never required, it may be ignored. Otherwise it now is easily and
quickly assimilable in a context of well-understood goal-directedness of
programming.
However, that was the good news. If that day of instruction is not
rapidly followed by more of the same, it trickles out of the classes’ heads in
no time. It leaves behind an impressive receptivity to related material, but
not enough to repay the effort and loss of momentum.
Also, the younger students show a curious tendency to forget, not
isolated facts and concepts, but integrated algorithms. Until they have used
several of them several times, the most gratifying receptivity and even creativity
in class is so much fairy gold. What is required is something like a week's
concentrated course. This may not sound much, but in eight-hour days it amounts
to some eighty classroom periods or nearly a semester at one period per day.
This can not generally be demanded in term time, but if the necessary
facilities can be located and an appropriately sized group of enthusiasts can
be assembled, much should be possible.
8. Parthian shot
one of the most
pathetic things i
have seen recently
was an intoxicated person
trying to fall
down a moving stairway...
archy
Don Marquis
One of the most tempting thoughts to arise
from the contemplation of a supply of youngsters with a sound basis in design
at the beginning of the curriculum, is the prospect of teaching them sound
follow-up material. In computer science at university level the typical
fresher with computer science as a school subject has as much to unlearn as
to learn, and one can say as much for the typical graduate entering industry.
Sound, applied practice is in principle no harder to teach than unsound, and a
good deal more rewarding. Unfortunately the challenges are three-fold: to teach the children; to teach the teachers; and to teach the
constructors of syllabuses; probably in ascending order of difficulty.
What this essay has discussed is in effect a three-fold objective. It
prepares students in fields other than Information Technology, for casual, informal,
but effective, computeracy, and it prepares those with a future in intimate
application or study of either Information Technology or Computer Science, with
a sound basis for formal study — inadequate inevitably, but with minimal
unlearning to waste resources on. It also, more fundamentally, should equip students with the concept of problem analysis and algorithm design for dealing with large classes of challenges that may have no direct connection with programmable devices at all.
References
[1] D. W. Barron, Recursive Techniques in Programming. London, Macdonald 1968, (quoting Gill, S.
1960).
[2] S.
Papert, Mindstorms: Computers and Powerful Ideas. Brighton.
Harvester Press 1980.
