For Loop = Modernist Drip


Above: a complex example using a “for loop”, in this case to draw semi-transparent 2.5d cubes

There are things that the computer excels at, but the thing it is best at is very fast calculations.  Computers are not very good at spur-of-the-moment or gestural ideas; in other words, things that require a flexibility of structure and action.  Of course, these are things that humans are quite adept at, and the foundation of most visual art practices rely heavily on this kind of movement and thinking.

The painter, on almost a gut level, can add a dab of this color and a bit of that to create the perfect hue.  His movements rely on the same palette layout and are practiced over years.  A woodworker learns the varying structure of a piece of wood and she can preemptively sense the moment when a stroke might be too hard and is likely to split the piece.

It is no surprise that computers are good at rigid and extremely fast mathematical processes: their evolution is built on this singular purpose.  One hundred years ago, a “calculator” was not a small electronic device or software built into your phone, but a profession.  The calculator was a person who performed mathematical calculations for a living, often in mass quantity, such as to create lists of logarithms.  In some cases, a whole shop of calculators would toil away.


Above: a mechanical “fire control” computer from the HMS Belfast (used to control gun turrets) via Flickr user f0rbe5; a patent drawing for a mechanical adding machine by (the other) William S Burroughs via Wikipedia

The problem with human calculation, of course, is that humans are fallible and repetitive hand calculations are prone to error.  Mechanical computers like Babbage’s fabled Difference Engine and later developments such as adding machines attempted to solve the problem.  As the weapons of war became more and more complex in the early 20th century – “hard” weapons such as motorized gun mounts, “soft” weapons such as code creation and cracking, and later the nearly non-physical nuclear weapon launch trajectories – computer engineering followed the path of the calculations.  Engineers built machines designed specifically for quick, complex operations that could be repeated over and over with subtle variation and extreme accuracy.

While strides have been made toward a more gestural and human kind of interaction (a subject well worth further discussion but out of the scope here), current computer architecture still privileges the repetitive.  Anyone who has dabbled in programming is familiar with the “for loop”.  The “for loop” is an iterative structure: it repeats itself over and over until a specific condition is met.

For example, if one was to want to draw a series of vertical lines next to each other at 2-pixel intervals, the code might look something like this:

 

The first statement (numberOfLines = 0) is our starting point, setting the variable numberOfLines to 0.  The next statement (numberOfLines <= 10) tells the loop how far to go – in this case to run until numberOfLines = 10.  The final statement (numberOfLines = numberOfLines + 2) tells the loop what to do each time it runs.  Here we add two every time.  Within the loop we have code to draw the line, which uses two sets of X,Y coordinates to draw vertical lines 10 pixels high and two pixels apart. *


Above: the result of the example “for loop” code, scaled up a bit

Understanding of the exact way the “for loop” works is not critical, except to emphasize that it works incrementally from a starting point until a condition is met.  With each increment some code is run.  Software architecture is full of these kinds of structures.  Cousins of the “for loop” include “while”, the ++ operator, and “if/then” statements.

Computers do a great job with processes like these.  Cranking out calculations at millions of times per second (the computer I am writing this text at is calculating 5.6 million times per second, or 5.6GHz), the computer is in constant spazz mode, running as fast as it can through discreet processes.


Above: iconic drips, Jackson Pollock’s “Autumn Rhythm (Number 30)” from 1950, via Metropolitan Museum of Art

Which brings me to the point: processes like the “for loop” are inherent to the computer and in seeing their evidence in algorithmic art and data visualization we are seeing the digital equivalent to the Modernist drip.  The drip became one of the primary symbols for mid-20th century art criticism, representing the primacy of material and an interest in removing artifice and representation in favor of materials remaining themselves.  Paint drips, and therefore is left on the canvas as evidence of its making and as a philosophical assertion of “paint as paint”.

I don’t see this as a value judgment of the current state of software: the project of Modernism has been thoroughly (exhaustively?) critiqued and most artists writing software I know don’t consider their work to have much of anything to do with Modernism (or its direct descendant Post-Modernism, for that matter).  Instead, they see themselves as interested in investigating and expanding networked culture, and in the discovery of new tools and methodologies for artistic exploration that straddle the macro-level of image making and cultural engagement, and the micro-level of code and bits.

Neither is this a call for artists and engineers to build computers and software that more closely mimics our interactions with physical objects.  While new interfaces like the Microsoft Kinect off exciting possibilities for novel interactions with computers, the inherent structure and operations of a tool can be as inspiring as an external stimulus.  Rather, by engaging the tools we have while examining them critically we ensure that we aren’t snared by their limitations and are free to make really cool stuff.

UPDATE:
Had a random thought the other day: paint drips, computers iterate.

*Users of the open-source language Processing will note that this code would be valid in Processing, though it certainly doesn’t do anything particularly complex.

Store and mill

Charles Babbage, inventor of the Analytical Engine – a machine for performing complex calculations that existed only on paper in his lifetime – split the concept of the machine into two functions.

STORE – the “store” was essentially memory, stored on punchcards as seen in the above image.
MILL – the “mill” did the actual computational work; in Babbage’s machine this was done with gears and levers.

Many more details on the history of Babbage’s invention in James Gleick’s book “The Information“.