Monday, July 30, 2007
Of Machines and Tasks
The programmer lives in a simple world. There are machines, and tasks. The task articulates an abstract need. The machine understands only primitive instructions. Between the two is a great gulf, occupied by the programmer.
The programmer builds a bridge over the gulf from both directions. The task must be specified, and the machine's instructions must be abstracted. The former results in a specification, and the latter in a program.
Hence, "programmer."
A better understanding of the programmer's mindset requires a better understanding of both tasks and machines, of both specification and abstraction.
Imagine this simple task: picking a quince.
In terms of efficiency, climbing the tree to pick its fruit is somewhat less efficient than reaching into the tree with a fruit-picker (e.g. stick) and knocking the fruit down. Later, the fruit-picker could also be used as a back-scratcher, tick-flicker, and fire-poker. The picking, scratching, flicking, and poking are tasks the user delegates to the machine.
I mean, the stick.
The specification process starts soon after.
"No, not that apple, the other one."
"Lower, lower, lower."
"Gently!"
"Get back from that fire."
These are all kinds of specifications. They make the task more specific. The stick-as-machine obviously cannot parse these instructions directly, but fast-forward a few thousand years and see what happens as the stick develops.
The world gets along with better and better sticks until folks in the middle part of the twentieth century come up with the bright idea of a general purpose machine. These machines can not only perform calculations, but also remember the results (as well as the calculation, for that matter). In turn, they can be used to control other, simpler machines (sticks, for instance) via input and output channels.
At the most basic level, these machines understand only a single kind of instruction: an electronic signal is either present or absent. On or off. Modern machines come with a number of primitive combinations of this basic instruction, but only a handful are needed to declare a machine complete, or Turing-complete.
Programmers, in turn combine these primitives into abstractions, to meet a specification. Thus, the bridge is built.
The programmer builds a bridge over the gulf from both directions. The task must be specified, and the machine's instructions must be abstracted. The former results in a specification, and the latter in a program.
Hence, "programmer."
A better understanding of the programmer's mindset requires a better understanding of both tasks and machines, of both specification and abstraction.
Imagine this simple task: picking a quince.
In terms of efficiency, climbing the tree to pick its fruit is somewhat less efficient than reaching into the tree with a fruit-picker (e.g. stick) and knocking the fruit down. Later, the fruit-picker could also be used as a back-scratcher, tick-flicker, and fire-poker. The picking, scratching, flicking, and poking are tasks the user delegates to the machine.
I mean, the stick.
The specification process starts soon after.
"No, not that apple, the other one."
"Lower, lower, lower."
"Gently!"
"Get back from that fire."
These are all kinds of specifications. They make the task more specific. The stick-as-machine obviously cannot parse these instructions directly, but fast-forward a few thousand years and see what happens as the stick develops.
The world gets along with better and better sticks until folks in the middle part of the twentieth century come up with the bright idea of a general purpose machine. These machines can not only perform calculations, but also remember the results (as well as the calculation, for that matter). In turn, they can be used to control other, simpler machines (sticks, for instance) via input and output channels.
At the most basic level, these machines understand only a single kind of instruction: an electronic signal is either present or absent. On or off. Modern machines come with a number of primitive combinations of this basic instruction, but only a handful are needed to declare a machine complete, or Turing-complete.
Programmers, in turn combine these primitives into abstractions, to meet a specification. Thus, the bridge is built.
Labels: book, programming
// posted by David @ 12:09 PM 
Subscribe to Posts [Atom]