Oct 06 2012

Programmer mind, mathematician mind: expounded

math programming

Ken Perlin recently wrote a post titled “Programmer mind, mathematician mind”. In it, he explains two different but complementary approaches to problem solving: one traditionally attributed to programmers, and one to mathematicians. I found this difference subtle but important, and my difficulties trying to explain this to a colleague prompted a post about it in more detail.

Ken’s concise description is “the former is procedural, whereas the latter is definitional.” Fleshed out, a programmer is attempting to find a series of steps to a goal, while a mathematician is trying to transform definitions to a goal. These sound pretty similar! To better demonstrate the difference, think about when either method goes awry. Let’s look at bad ways to define chess.

Bad procedural (‘programmer’) ways to define chess:

  • Chess is a game played on a grid made up of 4^3 squares.
  • Each side has two Bishops, these must always stay in the center of a square and may only move in integer multiples of sqrt(2) per turn.
  • If the King is taken, all pieces of the board must be reset to their starting positions on the next turn.

Note that these all ‘work’ in the sense that the original game of chess still functions under these rules. However, the reasoning behind the rules becomes obfuscated: why 4^3 squares instead of 64? Why not just say the Bishop always moves diagonally? Again, these are pathological cases meant to demonstrate how one ‘mind’ operates: in the case of the programmer, the ends justify the means. As long as the original game of chess somehow shows up, the exact definitions ultimately don’t matter.

Bad declarative (‘mathematician’) ways to define chess:

  • Chess is any game in which Garry Kasparov will win over almost all competitors.
  • A Bishop is any piece which moves diagonally.
  • If no other pieces are on the board, a King may not take a King.

These take the opposite extreme: instead of obfuscating the intention of each rule, the intention is made quite clear. Unfortunately, they fail from the utility standpoint: explaining that a Bishop is ‘any piece which moves diagonally’ is much less useful than ‘a chessboard starts out with two Bishops for each side, arranged like so, which only move diagonally.’ For a mathematician, the means matter just as much as the end does. However, unless you’re careful, you may not get to a satisfactory end!

Hopefully, this shines a little more light into the different forms of reasoning: programmers find rules to shift the machines in their heads (and their chips) to get the correct answer, regardless of how that happens. Mathematicians set up initial definitions and transformations which preserve ‘correctness’ through each step, and hopefully find a sequence of transformations which obtain the end result.

A final anecdotal observation: algorithms and implementations that are ‘elegant’ are usually the ones where the procedural and declarative styles meet in the middle. In this case, the implementation ‘falls out’ of the mathematics, and the result is very pleasing.

show/hide comment box