The Complex Question of Complexity in Programming

I spent most of last week grading semester projects written by my students. Reading through the code of beginners is really interesting. It’s interesting in part because of the solutions they come up with. You see in my first course we really only have a few weeks to cover programming. It is part of a full semester course and we do a lot of other things. So the tools that students have are quite limited. We don’t get to arrays for example. And the event handlers we deal with are pretty basic as are the objects they learn about.

One of the programs my beginners often select to program is the game “lights out.” This is how we describe it for students. When a student asks “is this hard?” I am tempted to answer “for you or for me?”

Lights Out – The game starts with 25 red buttons arranged in 5x5 grid. Each button pressed toggles itself and the four buttons around it (above, below, to the right, and to the left) between green and red. The object of the game is to get all 25 buttons green.

A typical board would look something like the image to the right. Most students wind up writing one event handler for each square on the board. Each event handler has between three (corners) and five if statements to determine color changes. I typically see something like a 14 page print out.

Creating this is at once simple and complicated. Simple because all of the language tools are very basic. Complicated because tracking all the squares that need to be checked is tedious and error prone.

My solution involves invisible boarder boxes and a single event handler that handles all cases simply and easily. Keeping track of what boxes to check is trivial. The print out is about 2 pages long and includes more features than the typical student project. This is also in some ways both simple and complicated. Simple for me because I have done this sort of thing many times before. Complicated because of the use of a two dimensional array (which my students haven't learned yet)  and because some students have trouble grasping why the invisible boarder makes the code easier and not harder.

Complexity seems to depend on a number of things. One is of course the “tools in the toolbox.” The more tools one has the more options one has. That’s pretty obvious. It seems like one of the biggest developments in programming in my time is the arrival of extensive libraries and functionality that is built into to programming languages. Anyone ever have to write code to subtract, multiply or divide? I remember doing that for a PDP-8 program I wrote in college. Everything was built on adding. I’m really class I don’t have to do that anymore.  Of course there is a lot more to learn as well.

The other thing is experience. The more code one has written and read (especially read) the more design options on knows and understands. After a while one naturally sees patterns that are not always obvious to beginners.

Teaching the basic syntax still seems like the easy part of learning to program. Understanding how those building blocks can be assembled is the hard part. There is still a lot of “reinventing the wheel” on the part of students as they “solve” well understood problems. That is part of the learning experience in many disciplines but I often wish we could move that part along faster. And less painfully.