The ever-trusty del.icio.us/TomC feed brings news of a debate related to the Processing or Die thread a while back. A blog post over on Grand Text Auto about a lecture by C.E.B. Reas at the Human Systems | Digital Bodies conference has drawn some interesting comments about “procedural literacy” and discussion of general terminology.

Michael Mateas, associate Professor at Georgia Institute of Technology, has posted a link to his paper "Procedural Literacy: Educating the New Media Practitioner" (PDF). In it he argues that a knowledge of computational processes (i.e. procedural literacy) is a requirement for anyone seriously intending to deal with the so-called “new media”. It’s slightly on the techy side of things, but has some interesting historical references (Papert, Kay, Nelson etc.) as well as some fresh takes on the basic problem of computing for the humanities. For instance, he proposes (writing) games as the perfect vehicle for understanding a procedural approach. Interestingly, another participant in the discussion, Ian Bogost, has a book out on MIT Press entitled Unit Operations : An Approach to Videogame Criticism.

The idea of computational literacy extends beyond what is traditionally considered code. Our favorite Norwegian blogger heroine, Jill Walker, forced her electronic literature students to learn HTML and CSS in order to set up their own blogs. While HTML lacks any active computational component, it can still potentially hold a transformative experience in terms of understanding how computers “think”. Just ask all the Myspace kids.

And of course there is always the dogmatic Open Source view as to why you should learn to code: If you can’t hack it, it will control your life.

An interesting link just came down Tom Carden's del.icio.us feed, by way of mflux posting it on Processing.org:

The Art in Computer Programming is an article by Andrew Hunt and David Thomas, both veteran programmers with views on how programming practices can be improved. At the core of the article is the assertion that programming can be seen as an art form, and that approaches from painting etc. can be gainfully used to improve the process of coding.

Comparing programming to art is not new. Donald Knuth’s monolithic series The Art of Computer Programming establishes the connection quite firmly, even if he uses art as a measure of quality rather than as a description of an aesthetic / critical practice. Paul Graham also seizes on the analogy to painters in his book Hackers & Painters.

Apart from some slightly distasteful analogies involving military scenarios of “hitting your target”, Hunt and Thomas have some interesting points that will be recognizable to experienced coders and newbies alike. The challenge of the blank canvas and writer’s block is familiar, as is the issue of when to stop. On these points the article gives clear and useful suggestions. The issue of “Satisfying the Sponsor” is all-important to software engineers and designers, but perhaps less critical to artists.

For another interesting take on how to program, read this quote from an interview with Bram Cohen in Wired 13.01. Cohen is the genius behind the notorious yet much admired BitTorrent filesharing protocol:

Final quote: “[premature] optimization is the root of all evil.” The author of this famous quote is the afore-mentioned Donald Knuth. It was mentioned in a post over on Vogon Poetry (again found through Tom C.) The post summarizes a talk by Cal Henderson on the building of Flickr, interesting reading as it describes how to create a scalable web application almost exclusively from Open Source software.

With its rich content and well-implemented tagging system, del.icio.us provides a tantalizing data set for would-be information visualizers. Fortunately, the open del.icio.us API allows developers full access to the functionality of the system.

To support the recently launched Processing hacks site I have written up a quick tutorial on how to access del.icio.us with Processing. The hack uses David Czarnecki’s delicious-java library. I also added a simple hack for outputting PostScript vector files.

Processinghacks.com

This site went live while Generator.x was having a holiday, but it deserves a repost even though it’s a few weeks old:

The ever-productive gentlemen Tom Carden and Karsten Schmidt (Toxi) have launched Processinghacks, a user-contributed Wiki intended to provide the Processing community with documentation of advanced techniques.

Processinghacks nicely fills the gap left by the lack of tutorials on the Processing site, combined with the beginner focus of the built-in examples. While a lot of answers are available on the forums, they are sometimes out of date or hard to find. Processinghacks provides details on specialized techniques that are beyond the scope of the core Processing project, such as integrating Processing with Java or hacking the source code itself.

A big plus is that this effort is completely independent of Ben and Casey, which means that they can focus their energies on the core project of bringing Processing to version 1.0. For those who remember the debate brought up by Karsten a little while ago, this should set an example. Instead of just complaining about the state of things, people like Tom and Karsten are actively providing a service to the community.

Some highlights from Processinghacks:

• Loading GPS data in the GPX format
• The definitive Processing in Eclipse tutorial
• Writing text on curves

Toxi aka Karsten Schmidt has been playing productive troublemaker the last few days, blogging some loose thoughts about what kind of tools and ideas are needed for a productive evolution of the computational design field. To roughly summarize: He is critical of the current state of the generative / computational scene, and the tools that are being hyped. Among his criticisms is that the work that is currently popular in the scene is often focused on immediate gratification, duplicating already existing work. It also often found lacking in niceties like software design, or even a more general understanding of good coding practices.

Karsten used Processing as the basis of his statements, pointing out that the procedural syntax of Processing could educate lazy coders and ultimately a dead-end for serious users of the tool. Not surprisingly, this has caused an explosive (but not incendiary) discussion over on the Processing forums. Ultimately, the discussion deals with the theoretical foundation for a tool like Processing, but also with possible future directions for the project. It’s on the techy side, but relevant for anyone who fancies her/himself a coder or who wants to understand what makes a programming language/tool capable of maximum freedom of expression.

Be sure to also read Karsten's followup where he clarifies his position after some misunderstandings.

Ah, yes, the holy Grail of programming: Writing software that writes software. Mostly it conjures up visions of films like the Matrix and Terminator series, featuring autonomous soft/hardware gone amok. But some people over at IBM think it’s underestimated:

The actual paper (by Jonathan Bartlett is pretty techy, but interesting:

- The art of metaprogramming, Part 1: Introduction to metaprogramming
- Jack Herrington has an online support site for his book Code generation in action

(via the RSS feed of del.icio.us/tomc, Tom Carden’s interesting bookmarks)

Joreg: triko

The clever boygroup boys over at Meso have released a new version of their patching programming tool VVVV , vvvv_33beta9. It fixes some bugs and adds a few nodes, as well as making a few old ones a bit more useful.

See our previous post for more info if this is the first time you hear of VVVV. As always, the vvvv screenshots on the Wiki contain a snapshot of what people have been working on lately, published directly from inside the tool.

Paul over at dataisnature.com blogged some nice links to VVVV projects, like Joreg’s triko music video and David Dessens’ shell-like objects. I can only second his approval.

Dave Griffiths: Fluxus

Fluxus is a new livecoding tool developed by Dave Griffiths, an artist working with software for generative art and live visuals. Fluxus uses the programming language Scheme (a Lisp dialect) to script a rendering engine with built-in 3D graphics and physics simulation. Fluxus runs under MacOS X only.

The scripts are executed and evaluated in realtime without compilation, and can therefore be programmed on-the-fly. This process is described on the TOPLAP wiki: Live Coding of Graphics. Fluxus also allows audio input and OSC data to be used as parameters.

This style of always-executing programming is called livecoding, and is described in the draft manifesto of the TOPLAP group. Livecoders propose a hardline approach to the understanding of software-based art: The code and the process of writing it should be visible to the audience, and not hidden inside a “black box”. This attitude falls in line with a group of artists generally described as software artists. Software art is concerned with the politics of the software in itself, whereas generative art is more commonly concerned with its output. Theorists like Florian Cramer and Inke Arns have written extensively about software art.

Meso: VVVV visual programming tool

VVVV is a patch-based visual programming environment for real-time graphics, video processing and installation control. It was created by the Meso group in Frankfurt, who originally designed it as a tool to develop their own projects.

Similar in operation to Max/MSP but focused on visuals and show control, VVVV is Windows only, sacrificing portability for hardware acceleration using DirectX 9. It’s free software, but not Open Source. It’s visual programming style makes it a unique alternative to text-based programming systems like C++, Java, Flash or Processing.

One of the most exciting uses of VVVV is for live visuals. Unlike compiled programming languages, patching systems like VVVV are constantly running, so it’s even possible to “program live”. In performance use the tool feels very responsive and allows live improvisation. Using the AudioIn and FFT nodes, sound-responsive graphics are easy to create. VVVV also interfaces easily with a wide range of input and output protocols such as RS232, MIDI and DMX-512 for show control or installation use.

The most unique feature of VVVV is the “boygrouping” feature. Boygrouping is a way of setting up a piece to render on a cluster of separate PCs using a master-slave distribution setup, allowing easy multiple-projection output.

For examples of the tool in use, see the Screenshot of the day, published by VVVV users directly from the software itself.