Program Design as the Tool of Preference in Computer Literacy Education:
Experience, Incentives, Implications
6. Key points in the procedure
6.3 Concepts of data and data manipulation
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.
No comments:
Post a Comment