For some time I have been concerned that discussions on the "Computing At School" mailing list, and in the press, in blogs, and radio and television broadcasts about what should be taught in Schools are based on a vision of computing that is too narrow, even if all the different views regularly expressed are combined!
This web page offers a list of important types of programming that should be
taught in schools but without making specific recommendations as to which should
be taught at what age to whom, or by whom, or why. This is a modified version of
the list of programming tasks in the web page on "Thinky programming and other
kinds" which includes growing collection of examples, especially "thinky"
examples, available here:
Below is a provisional list of such types of programming for learners. Different types may suit learners (and teachers) with different interests and temperaments. No suggestion is made here that some are better or worse than others. They all have potential uses, and all can have some role in education, though not all will be equally useful for all learners. For example, some types may be too intellectually challenging for a minority of learners whose rate of learning is slower or who find mathematical thinking very difficult. Some types may be too intellectually challenging even for the majority of learners. But that's not a reason for not offering them to the small subset of students who could gain great benefit.
The phrase "bumpy program" is a little too specific for this general category, since I don't want to imply that all the instances involve objects moving around and making contact with other objects. Alternatives might be "fun program", "gee-whizzy program", "entertaining program". Suggestions welcome.
A website illustrating this category is: http://www.netmf.com/gadgeteer/
There are several kinds of programs designed to produce something funny, e.g. puns, acronyms, limericks, etc. These could be put in a separate category or treated as a sub-category of "arty" programs.
Arty programs can overlap with some sorts of 'Thinky' programs, below, depending on how much of the design, or creation, is done by the program, as opposed to the user of the program (as in creating a PowerPoint presentation). Richard Dawkins and others have shown how evolutionary computation, driven by user preferences, can create interesting "arty" results, e.g. pictures or music.
Some presentation tools are internally very sophisticated, but give the user only very shallow modes of composition, too shallow for the purpose of teaching programming, or computational thinking, while others can present programming challenges of high intellectual difficulty.
Some modelling programs are concerned with 'thinky' systems, described below. Some are part of a gadgety program: e.g. a program that controls an external machine or device, and chooses control strategies partly on the basis of modelling the behaviour of the device, to predict consequences of alternative strategies in changing circumstances.
Programming is exploratory when programs are not written with some well defined initial specification of what is required, against which the programs are to be evaluated. Instead, exploratory programming is used as a way of trying out ideas, to see what happens.
In deeper versions, this may be a way of gaining an understanding of a class of structures or processes, for example, studying ways in which polygons can vary under various sorts of constraints, or ways in which algebraic expressions relate to the shapes of graphs, or investigating the proportion of algebraic structures of a certain type that also have some specific property.
This is often a good way to explore a class of mathematical structures, or a class of algorithms and a variety of possible ways of developing or extending some sort of tool. For example, if you write a program that generates lines in 2-D display, and involves various numbers corresponding to lengths, angles, numbers of times something is done, you can experiment with ways of changing the numbers in order to understand the set of possibilities.
In order to explore ideas about numbers you can try pretending that the computer can manipulate lists of symbols, e.g. [a a a], but has no arithmetical capabilities, and then try to program it to understand numbers and arithmetical operations. This can help learners to acquire a new deep understanding of the nature of numbers. See also http://www.cs.bham.ac.uk/research/projects/poplog/teach/teachnums
In order to investigate ideas about probabilities you can use a computer to systematically generate a collection of cases (e.g. the sets of numbers you can get by throwing three dice) and then work out the probabilities of various combinations (e.g. combinations of three numbers that add up to five) by seeing what proportions of the whole set of possible combinations includes combinations totalling five.
In that case the computer can generate the sets, count their elements and find the ratios. It can also plot graphs displaying, for example, how the probability of getting a throw adding up to N varies with the number of dice thrown.
Someone playing with such programs can notice something that was not
planned and then change the program to explore that new feature. As
with many toys, and many kinds of mathematical or scientific
research, what you experience while "playing" or "exploring" can
suggest new questions, new things to try, new hypotheses to test,
new explanations of previously discovered patterns, or refutations
of conjectures (e.g. by producing an unexpected counter example).
An example of an exploration of random walks is here.
An example of exploratory programming related to Russell's Paradox and the paradox of the barber who shaves all and only those shavers who do not shave themselves is here.
Unfortunately educational practices that take students through a collection of set tasks may fail to teach deep exploratory skills required for discovering new, interesting, tasks.
On a larger scale, utility programming, or application programming goes far beyond what can be accommodated in primary and secondary education, including design and implementation of compilers, interpreters, device drivers, operating systems (and their many components), networking systems, security systems, financial services, remote servers of many kinds, and a wide range of systems for controlling machinery including chemical plants, airliners, power distribution systems, and many more. In some cases it may be possible for teachers to design projects around "toy" versions of such systems.
The main point is that much of what these programs do, like thinking in humans, is invisible, though the results of the internal processing may be made partly visible by testing the programs. For example, a program that has learnt a new language may be able to answer questions posed in that language. A program that has learned to understand diagrams, may be able to produce descriptions of diagrams or may be able to create a diagram matching a description, such as "A square containing a circle above a triangle and part of a horizontal line sticking out to the left of the square".
Often it is very difficult to design a "thinky" program to perform a task without first doing a lot of exploratory programming to find out what design possibilities there are and what their consequences are. This is why most AI languages offer support for optimising human exploration by programming rather than emphasising support for optimising some end product to be put on the market (which would sometimes be written in a different language from the one used for exploration and development).
For example use of list-processing as a general mode of representation of structured information, instead of developing a collection of classes and methods, can often facilitate very rapid and flexible exploration of a class of algorithms with strong support for run-time interactive modification of code and structures while exploring the domain. Use of run-time type-checking as opposed to compile-time type-checking can sometimes speed up exploration even if code would run faster in the latter case. (Many of the hardest programming errors to identify and fix are of a "semantic" variety that would not be detected by syntactic checking.)
Examples of "thinky" programming tasks of varying difficulty are available at http://tinyurl.com/thinky-ex. Some are particularly simple, because they are meant to be suitable for absolute beginners. Other examples were once regarded as suitable for PhD projects in the early days of AI, though with modern AI programming tools the programs are much simpler to create than they were originally.
A type of thinky programming that has a long history in AI is programming a machine to write programs, otherwise known as "automatic programming". A type of example that might be used in the classroom could be a program that takes in a verbal description of a task and then generates code to perform that task: e.g. "Draw a triangle with a square on the left and a circle enclosing both", or "Draw a cat in a box with the body of the cat hidden by the sides of the box". There are many more possible examples.
In particular, we risk seriously impoverishing the pool of talent entering many of the higher education and research disciplines (including non-computing disciplines) that are increasingly using computational thinking and modelling as part of their subject matter, rather than merely using tools to format their papers, construct their presentations, or process their empirical data. This impoverishment has already happened in the last three decades and many disciplines are suffering as a result, whether their practitioners know it or not.
Likewise we impoverish our future if we teach only a small subset of programming languages, e.g. the ones based on sequences of instructions organised by loops and conditionals, enhanced by procedures, or even object-oriented programming. There are many other programming paradigms including rule-based programming, neural programming, evolutionary programming, constraint-programming, stochastic programming, logic programming, pattern-based programming, event-driven programming (e.g. interrupt handlers), functional programming, and programming in languages designed for particular types of application domain. Some of the topics above also require learners to think about architectures combining several computational paradigms, and also about the need to understand and model not just what goes on inside a computer (or animal, or device being modelled) but also the environment it interacts with.
It is also important to remember that Computer Science is not merely a programming discipline, as many people discussing the inclusion of more computer science in the curriculum seem to assume. It has rich theoretical content including applications of advanced mathematics to specify the nature of various types of computation, explore their scope and limits, prove or disprove claims about particular programs, investigate similarities and differences between different sorts of programming languages, and many more. Much research on "thinky" programming is concerned with the scientific task of finding out whether computing systems as we know them can do all the things done by brains, for example, and if not whether new types of computer (e.g. chemical computers, quantum computers, or neural computers) and bridge the gap.
Cynthia Selby kindly read a draft in July 2012 and made useful corrections, comments and suggestions some of which will probably be taken up later, either in this file, or a related web page.
This is part of the
Free Poplog Portal
Enquiries to A.Sloman@cs.bham.ac.uk
This file maintained by:
Installed: 8 Jul 2012
Last Updated: 9 Jul 2012; 22 Jul 2012; 23 Jul 2012; 10 Jul 2015 (format)