Forty years ago, when Donald E. Knuth titled his magnum opus The Art of Computer Programming, he was playing with our sense of incongruity. According to the stereotypes of the time, art and computation belonged to different spheres of life; they appealed to different kinds of people; they required different skills. The meticulous, logic-driven process of constructing a computer program didn't look like an arty activity, and the output of a program seemed unlikely to qualify as artwork. Since then, the stereotypes have softened somewhat, but I suspect that the words "artist" and "programmer" still evoke rather different mental images. Casey Reas and Ben Fry are doing their utmost to change that.

Reas and Fry are the inventors of a programming language called Processing, which is specifically intended for creating work in the visual arts. They conceived the language almost a decade ago, when they were students of John Maeda in the Aesthetics and Computation Group in the Media Lab at the Massachusetts Institute of Technology. (Fry is now with the Broad Institute in Cambridge, Massachusetts; Reas is at the University of California, Los Angeles.) They released their language into the wild as a freely available, open-source project, and it soon attracted a worldwide community of enthusiasts. By now there are thousands of Processing "sketches" (as the programs are called) to be found on the Web. A good place to start looking for them is processing.org, where you can also download the language software.

The book Processing is addressed primarily to an audience of graphic designers and artists. It offers a very gentle introduction, requiring no prior experience in computer programming and little knowledge of mathematics or algorithms. The main thread of the narrative is a hands-on tutorial: You are encouraged to type in the programs as you read them (or else download them from processing.org), and to experiment with variations. The lessons begin with the necessary nitty-gritty: rules of operator precedence, coordinate systems, how points and lines are represented, what a for loop looks like, how to encode colors in hexadecimal notation, and so forth. Beginning at the beginning is always a sensible approach, although it does mean there's a fair amount of work—and not a whole lot of immediate gratification—before you get to teach the machine any really clever tricks. Then again, learning a new artistic medium is never effortless, and I would venture a guess that most people can reach reasonable competence in Processing much faster than they could master a paintbrush. Moreover, the sequence of lessons is broken up by several interludes of lighter fare, including a few dozen interviews with software artists who show and explain their work. (Not all the artists work with Processing.) Toward the end of the book some larger and more elaborate projects are presented in detail.

The Processing language is built on top of Java, a general-purpose programming language introduced in the 1990s and now the most popular language of instruction for computer science courses. Processing borrows most of its basic syntax from Java but also has some specialized commands and data structures for drawing. (A typical Processing sketch has two main procedures, named setup() and draw(), which have no counterpart in a generic Java program.) Behind the scenes, Processing programs are translated into standard Java and executed by the Java runtime system that comes preinstalled on most modern computers. And because most Web browsers support Java, it's straightforward to embed a Processing sketch in a Web page.

The Processing language is an interesting and powerful tool, but perhaps even more important than the language itself is the software environment that comes with it, and the community that has grown up around it. Processing comes equipped with a simple editor program that formats code as you type it in; for example, keywords are given distinctive colors, statements are indented appropriately to reflect the program's grammatical structure, and unmatched parentheses are flagged. There's help diagnosing common errors (the inevitable missing semicolon). And running a program is a matter of pressing a single button. None of these facilities represents any deep conceptual breakthrough in software engineering, but taken together they are vitally important in lowering barriers to entry. The system rewards an exploratory style: You are encouraged to just try things out and see what happens. This might not be the ideal protocol for writing airline flight-control software, but that's not what Processing is meant for.

The community of Processing enthusiasts has also made important contributions to the success of the whole enterprise. Although Reas and Fry created the language and have guided its development, many others have enhanced and extended it. At last count, the online forum for Processing discussions had 23,344 members. A multitude of published sketches serve as models and inspiration. And Processing has even expanded into hardware technology: An inexpensive electronic device called Arduino allows Processing programs to interact with the physical world. The final chapters and appendices of the Processing book discuss some of these extensions.

Ben Fry's second book, Visualizing Data, presents the Processing software in a different context: as a tool for creating plots, maps, charts, tables and other kinds of information graphics. It's a shorter book with a quicker pace and less hand-holding than the Reas-Fry volume. Fewer projects are presented, but they are explored in greater depth. For example, Fry gives a step-by-step ­account of how he built one of his own impressive demonstrations, called Zipdecode (see benfry.com/zipdecode).

Software publishers offer many tools for data visualization, ranging from spreadsheets to statistics programs to graphing software such as Gnuplot and even online resources such as Google Charts. Most of these alternatives are highly automated: You dump in the numbers and get back a graph. Constructing the same graph with Processing requires substantially greater effort, which raises the question of why anyone should bother. Fry's answer is that there are many techniques of data visualization beyond the standard bar chart and line graph, and a programming language is the most effective tool for exploring the possibilities. And even for conventional charts and graphs, the Processing environment offers greater control and flexibility.

Either of these books serves as a useful introduction to the Processing language. They differ in emphasis, one focusing on pure self-expression, the other professing more utilitarian aims. Where Processing introduces artists to the seductions of technology, Visualizing Data urges scientists and others who work with quantitative data to be more thoughtful and creative in making pictures. But the dividing line between art and infographics is not always clear. An array of colorful rectangles in Visualizing Data is presented as a map of the contents of a computer disk (see facing page); if the same illustration had appeared in the Reas-Fry Processing volume, it might have been labeled art.

What I find most heartening about the whole Processing phenomenon is the hope that it will induce more people to look on computation as a creative medium open to everyone. I find it sad and ironic that the world is full of machines whose defining characteristic is programmability, but few of us ever write programs. We spend our days sitting in front of computer screens, twiddling the dials of software created for us by a technological elite. A programming system like Processing—lightweight and approachable—promises to spread the fun more widely.

I do have one minor misgiving about Processing. I'm not at all sure that a gerund or participle makes the best possible name for a language, or title for a book. This one always seems to leave me standing at the checkout counter, waiting for my credit card to be approved.