Programming

What to expect

This chapter discusses programming, looking at the history of programming education from Knuth’s “programmers’ bible” through the UK’s 1980s computer literacy project, to computational thinking, Barefoot and PRIMM.

An extract is below:

It’s not about code

Dijkstra’s said “Computer Science is no more about computers than astronomy is about telescopes” [1]. However you learn to code and whatever language you choose to do it in, it’s important to remember that programming is not about keywords, punctuation and indentation, but about problem solving.

When Peter Samson learned the opcodes of the Tixo, he did so to solve problems. He wrote his music player to solve a problem, namely “How can I make this machine play Bach?”. The 9-man and 1-woman team who created the FORTRAN compiler wanted a quicker way to code mathematical programs needed to design aircraft, so they wrote a compiler to solve that problem. Then everyone used the compiler and wrote high-level programs to solve the mathematical problems. When Katie Bouman wanted to take a picture of a black hole by combining images from several telescopes, she wrote a program to solve that problem.

Programming exists to solve problems using a machine. To do this, you must find a way to state the problem computationally, then get a machine to perform the computation. The first part is what we now call Computational Thinking. It’s easily the largest part of the process, but often overlooked by novice programmers and expert instructors alike.

Dijkstra quote link

Concepts not Constructs

Despite all this research telling us that programming is really problem solving with code, and the major new skill learners need to acquire is not “coding” but “computational thinking”, picking up an introductory programming textbook or using an online programming tutorial for a few minutes reveals a depressing fact: programming tutorials focus almost exclusively on syntax, not the process of developing a program to solve a problem. This issue has been around over thirty years:

“Suppose you attend a course in cabinet making. The instructor briefly shows you a saw, a plane, a hammer and a few other tools, letting you use each one for a few minutes. He next shows you a beautifully finished cabinet. Finally, he tells you to design and build your own cabinet and bring him the finished product in a few weeks. You would think he was crazy!” – (Gries, 1974)

Most programming books are structured according to the language constructs, e.g. “The While Loop”, “The If Statement” which are the tools of code, but the process of choosing the right tools, using them in the right order, putting together the pieces, testing and refining the product appears to be, as Caspersen note, “swept under the carpet as an embarrassing secret.” (Caspersen, 2018^[ii]) Instead we should focus on the process of programming, progressing through concepts in order of complexity of tasks, not complexity of language constructs, teach the programming process explicitly, encourage the development of a notional machine in the minds of the learners (see below) and follow a use-modify-create model where learners progress “from consumer to producer.” (Caspersen, 2018) We explore these processes in the Pedagogical Content Knowledge section of this chapter.

References

The PCK section in this chapter includes these references:

[37] K.L. Bouman’s testimony to US House Committee on Science etc. May 16, 2019 link

[38] Email to University of Virginia Computer Science mailing list, Dijkstra, June 1975. link

[39] BBC’s “The Computer Programme”, episode 2, February 1982 link

[40] Steve Furber, foreword to “Shut Down or Restart”, Royal Society, 2012. link

What to expect

It’s not about code

Concepts not Constructs

References

Share this:

Like this: