Lambda the Ultimate

inactiveTopic Processing: A language for visual arts
started 1/18/2004; 5:53:01 PM - last post 1/20/2004; 8:57:25 AM
Dave Bauer - Processing: A language for visual arts  blueArrow
1/18/2004; 5:53:01 PM (reads: 148, responses: 2)
I found an interesting juxtaposition in my news aggregator. Right above Lambda The Ultimate was a link to http://processing.org/.

Here is a quote from the main page: " Processing is a programming language and environment built for the electronic arts and visual design communities. It was created to teach fundamentals of computer programming within a visual context and to serve as an electronic sketchbook. "

Darius Bacon - Re: Processing: A language for visual arts  blueArrow
1/18/2004; 7:59:16 PM (reads: 147, responses: 0)
Paul Ford has some meditations on this at http://www.ftrain.com/ProcessingProcessing.html
Looking at Processing, I find myself thinking: I wish the web worked like this. I don't wish the web was a collection of little clickable graphics, but rather, I wish that people would take a step back and look at everything we've done and "elegantize" the Web as a construct, define a set of core goals that web developers want to solve and create as small as possible a language, based on the smallest possible set of principles, that will help them meet those goals.

Kimberley Burchett - Re: Processing: A language for visual arts  blueArrow
1/20/2004; 8:57:25 AM (reads: 84, responses: 0)
I blogged about this here. Here's my take on the language:

I expected it to have a much different feel than it does. I expected a domain-specific direct-manipulation model, and I got a thin procedural wrapper. For example, consider the RGB Cube demo. I'd expect the source code to look something like this:

#pragma 3D_WORLD
Square s;   (implicitly centered in the viewport)
s.all_faces.shading_method = 
        Shading_Method_Interpolate_Vertices;
s.vertices.front_upper_left.color = black;
s.vertices.front_upper_right.color = red;
s.vertices.front_lower_left.color = green;
s.vertices.front_lower_right.color = yellow;
s.vertices.back_upper_left.color = blue;
s.vertices.back_upper_right.color = purple;
s.vertices.back_lower_left.color = cyan;
s.vertices.back_lower_right.color = white;

on mouse_move { s.rotate_around_x_axis(mouse.delta_x); s.rotate_around_y_axis(mouse.delta_x); }

But the actual language is much easier to implement, and much more disappointing from a user's perspective.

  • Instead of having things like mouse movement deltas readily available, you have to explicitly remember the old mouse position, and subtract it from the new position.
  • The square, instead of being an object, is defined as a series of calls to the vertex() function, preceeded by beginShape(QUADS), and terminated by endShape().
  • The color of the vertices is also completely dependent upon the order of function calls -- you call fill() to set the global color, and that gets inherited by the calls to vertex().
  • There's this completely non-intuitive idea of push() and pop(), to save all the global variables, presumably so that cumulative calls to translate() don't walk you off the screen. At a minimum, I would have expected the loop() function to have implicit calls push() and pop().

In other words, Processing seems to be nothing more than a thin layer over OpenGL, implemented inside a Java applet. That's probably a good approach if your goal is to teach programming, but seems suboptimal for quickly sketching designs.

I've got to admit though, some of the applets are really cool.