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:
http://www.cs.bham.ac.uk/research/projects/poplog/examples/

Programming tasks

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.

Types of programming task

• Numbery Programming:
• Bumpy Programming:
• Gadgety Programming
• Arty Programming
• Presentation Programming
• Lifey Programming
• Modelling Programming
• Exploratory Programming
• Utility (or "Appy") Programming:
• Gamey Programming:
• Teachy (tutorial) Programming:
• Thinky Programming:

• Numbery Programming:
  The oldest type of computer program -- adding, multiplying, averaging and performing statistical operations on one or more numbers, or doing matrix and vector operations, or equation solving operations, as well as drawing graphs of numerical functions.

• Bumpy Programming:
  Many tasks designed for very young learners fit into this category. These are concerned with controlling movements and changing appearances of real or simulated mobile devices, like the LOGO physical or graphical turtle, or interactive video-based game programs involving bumping, shooting, eating, avoiding, etc., often with accompanying swishes, bangs, thumps and other entertaining noises. The tasks and the programming environments supporting these can vary from very elementary to professional.

  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.

• Gadgety Programming
  These are programming tasks concerned with controlling devices outside a computer (e.g. the Arduino). Some gadgets merely respond to output from the computer, e.g. a gadget that flashes lights or makes noises under the control of the computer. Others send signals to the computer from sensors in the gadget or buttons, or knobs, or levers on the gadget that a user can manipulate. Some gadgets may be used to control other machines, e.g. a digital thermostat that controls a heater and is itself controlled by a computer.

  A website illustrating this category is: http://www.netmf.com/gadgeteer/

• Arty Programming
  E.g. for generating poetry, stories, pictures, music, dancing robots and other works of art?

  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.

• Presentation programs
  There are many tools that enable a human designer or author to create something to be presented to others: a poster, a musical performance, a presentation, a document to be read, an advertisement, etc.

  Some of these merely take in very explicit instructions and obey those instructions, for example a WYSIWYG text formatter where the user is constantly assembling the text, specifying spacing, indentation, font style and size, where the line breaks should be, as well as the actual content. Others allow the user to specify, in a "markup" language, what needs to be done at some level of abstraction, leaving it to the program to work out how to achieve that, e.g. where to break lines to produce left and right aligned text, or which numbers to assign to numbered paragraphs or figures. Simple examples include html, nroff, and others that were widely used in past decades, while more complex examples, some of which are extendable by sophisticated user-defined macros, include Troff, LaTeX, PHP, JavaScript and other systems used in web design.

  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.

• Lifey Programming
  These are programs written using 2-D patterns in a 2-D grid, which when run generate new patterns. The most famous example of this sort of thing is Conway's 'Game of Life'. There is an excellent overview, along with a superb interactive Java applet here http://www.bitstorm.org/gameoflife/
  Another (launch applet using button on top left labelled 'Enjoy Life') is: http://www.ibiblio.org/lifepatterns provides several additional links.
  See also: Some notes on the 'Life programming language'

• Modelling Programming
  These are attempts to model the structure or behaviour of some previously existing system -- e.g. the solar system, ant foraging, insect swarms, water pouring out of a jug, sand castles collapsing, traffic "pressure waves" on a motorway, traffic flow in a busy city, financial transactions, and many more. Some of the tasks for learners can be fairly elementary, especially if based on well-designed libraries. Others can tax even advanced researchers, e.g. modelling weather patterns.
  Much of modern science in a variety of disciplines makes heavy use of modelling programs, so learning to build a variety of types of modelling programs can be useful for many careers in science, engineering and management.

  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.

• Exploratory Programming
  This notion is orthogonal to the other types of programming: any of them could include exploratory programming, but need not -- if used to program a solution to a well understood problem.

  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.

• Utility (or "Application" or "Appy") Programming:
  A great deal of human effort now goes into making utility programs. These may be simple but frequently used applications e.g. a program to set an alarm to go off after a set time, or very complex utilities written to solve a particular problem, e.g. searching for a way of decoding a particular coded message. The wide-spread use of programmable smart phones, supported by mechanisms for making new "apps" available to many users (possibly at a cost) has encouraged many teachers and learners to focus on "appy" programming. This category overlaps with most of the others insofar as the utilities may serve any of the purposes listed here, including teaching programming.

  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.

• Gamey Programming:
  These are programs that either play a game with a user (e.g. chess, Go-Moku, Nim) or support a game being played by two or more players (e.g. managing a game of chess, or monopoly) or present users with some puzzle solving activity, or test of some kind of skill, e.g. Solitaire, or Tetris. This category can overlap with others, especially "thinky" programming where the computer has to compete with a user by making plans, choosing moves, solving problems.

• Teachy (tutorial) Programming:
  These are programs that teach a user something, which may be factual, e.g. about a geographical region, or a period of history, or some branch of chemistry or biology, or which develop a practical or intellectual skill, such as typing, spelling, doing arithmetic, doing logic, speaking grammatically, understanding geometry, etc. This can also overlap with other categories, especially gamey programming (since many games are educational) and "thinky" programming since an intelligent tutoring program does not merely go through a list of tasks presented to the learner but may also need to respond to questions from the learner or select or construct tasks designed to match the attainments and misunderstandings detected in the learner. For example, a chess program that automatically adjusts its level of play so as to challenge the opponent and educate the opponent (which no current program can do, as far as I know) would be a thinky-teachy program!

• Thinky Programming:
  The aim of a "Thinky" program is not usually to produce a working system whose behaviour is useful or entertaining, or helps the programmer understand some piece of science or mathematics, but to teach learners about ways of getting machines to do some of the things humans and other animals do when they perceive things, learn things, solve problems, achieve goals, make and execute plans, solve puzzles, communicate in sentences, compose poems or music, or engage in competitive games where winning is not a matter of being, big, fast, or physically skilled, but requires use of intellectual powers.

  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.

Comment

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.

Suggestions for improvement are welcome.

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