What follows is a brief explanation of what programming is, to someone like me. I am a minimalist, and I see programming as mainly a process of removing unnecessary moving parts and features—not removing the essential behavior, of course, just elements of the code. This is for people who don't know much about programming, but also for people who do.

Most people who have done a little programming have seen the famous for loop. A for loop typically looks something like this:

  for i := 1 to 25 do
    do something with array[i]

That says, "let the variable i take on the values from 1 to 25, and for each value, do something with the ith element of the array." 'The array' is some ordered list of objects, such as blog posts, files on disk, celestial obesrvations, income receipts, or frames of porn video. A loop like the one above would typically be written if you knew the array actually had 25 elements in it. You certainly wouldn't want to do this if there were less than 25 elements in the array, because then the code would end up trying to work with an element called array[25] even though it doesn't exist. So you have to know how many elements are in the array, and you have to keep the first line of the for loop in sync with that.

This example is so deeply embedded in the history and culture of programming that it's hard to imagine that anyone who has studied at least a half a semester of programming has not seen this construct. "Looping" seems to be the simplest non-trivial example of anything in computer science.

Yet, speaking as a professional programmer, I almost never use this form. It's almost never the right thing for my needs and my tastes.

In this example, note that I'm just operating on each element of the array once. The number of operations I do should really always be the same as the number of elements of the array. A more direct way of expressing this would be something that means "Do this operation on each element of the array." This is easy to write down, and most modern programming languages have some standard way to do this. Here's what it looks like in haskell, perl, scheme, python, and ruby, respectively:

  map ( \theThing -> do something with theThing ) array
  map { do something with $_) } @array
  (map (lambda (theThing) (do something with theThing)) } array  # see [1]
  map(lambda theThing: do something with theThing, array)
  (array.map { |theThing| do something with theThing }
  map (fn theThing => doSomething with theThing) array

"Map" is a word inherited from mathematical vocabulary, but I like to think of it as constructing an ordinary sort of map—a streetmap, if you will—from the input array. The streetmap has all the parts of the city, yet only in miniature: by analogy, each element in the result—or each little bit of action that this instruction performs—corresponds to one of the elements in the original array. You can't make a map without surveying the whole city—and it would be some horrible kind of map if you mixed up the streets of the city, repeating some or re-arranging them. In the same way, the "map" command in programming languages makes a faithful map, containing an image of all the parts of the thing mapped, and keeeping them arranged the same way.

[1] The keyword "lambda" in this context comes, oddly enough, from the history of logic, and it still lingers in a couple of today's popular languages, even though it has no everyday meaning that evokes its function. In fact, it has no special function except to highlight the part of your program that assigns a name to the individual array element that's being processed. Since its only function is to call out a specific point in the line, many languages do away with it, such as ruby which uses pipes (|theThing|) to surround the name.

The map form is a tighter form than the for loop, and a minimalist should prefer it. In the original "for" loop, things were kept in order by means of the variable "i". But we never really cared about the "i" itself—we weren't printing it out or storing it anywhere (I mean, when programming, we typically don't). The "map" form dispenses with that distasteful number and expresses exactly what the programmer wants: do something for each element of this list. "Map" doesn't bother with numbers; map simply knows what's what in the array, and makes an image of each part, according to your given code. "Map" is like a child, who can easily turn over every coin on a table without having to count them.

As soon as you get comfortable with the "map" form, you realize just how extraneous the numbers were—the numbers 1 and 25, which are written into the program, as well as the intermediate numbers that "i" takes on. In fact, being extraneous, these circumlocutions begin to seem kind of dangerous: after all, we had to keep track of that limit number 25, and make sure that it always showed the size of the array. If something changed, we might forget to update the 25, in which case the program could be totally broken. Since the numbers can be wrong, why bother with them at all?

Many people may think of programming as a task of logical deduction, and it does call on that skill at times. But in the process of programming, you need to take time to rough things in, to think creatively, make experiments and strange intuitive forays, side-trips which don't have a perfect logic and may not be quite right. When you're finished, though, when you've discovered what you were trying to discover, you need to make it "right" and taut. You need to grab the little string that hangs out of the program and pull it tight so that all the superfluous bits come away, and your program is just what it needs to be. I like to call this the "principle of least shape." When you look at the program, you can see its shape, and the shape helps you understand the program quickly, or else obscures the program, if the shape is too ornate, too complicated. The principle of least shape ensures that you can read the program quickly, and that there are no unnecessary moving parts to break. In the end, the form of the code (in a sense) closely follows its function.

When I do this, pulling the string tight, I nearly always find that the numbers go away. Numbers are not very useful, it turns out!—at least not in programming.

The goal of my brand of programming, and an important goal in language design, is to find these places where programs are too complex, and to find the construct that does just what they need with no extra. In some languages you are constantly putting in unnecessary bits of string (complex shapes) because the language itself relies on unnecessary shapes. Some languages, for example, make it difficult to use "map" as I discussed above, and push you towards using that circumlocution of the index "i".

Forthwith: other examples.