April 7, 2006

Casey Reas, code>conf

by Mary Flanagan · , 3:49 pm


[reas' process-ed work "Path 14"]

Some observations drawn from Friday’s keynote lecture at the 2006 iDMAa + IMS Conference- HumanSystems | DigitalBodies follows!
For the last two years, Casey Reas has been writing software utilizing the principles of emergence and simple machines and ‘vehicles’ which develop neural systems. His work is created these days primarily using Processing (surely blogged about before on gtxa)…

Over time, Reas’ beautiful creatures begin to move together when they discover they are ‘alike.’ Paths in space are explored as positions over time in relationship to other ‘vehicles’. Stimuli in the environment causes reactions among similarly configured organism systems. The forms that emerge out of the software are in no way predetermined, but the structures do summon organic structures, especially of plants. Working with computing is constrained, but working with emergence is wide open. So Reas aims to focus on the organic surprises …

Reas discussed his vehicles and process-based works, then discussed Processing.org and the value of teaching Processing instead of other introductory languages. He argued that processing neither belongs to computer science or the arts, so because it does not belong to any particular discipline, it can help folks from both either become more technically proficient or more visual. Unlike Java, Processing is specifically built for motion and interaction. Arguing for teaching programming through a “Motivation by Images,” Reas showed new examples not seen in the gallery on Processing.org. The social components to the project: not only free to use and modify, but avail for Windows, Mac, and Linux. The international participation is quite high in the Processing community.

The strategy proffered by Processing: to start off with procedural programming and move into OOP, is also supported by Ira Greenberg in his new book on Foundation Processing, coming out soon from Friends of Ed.

15 Responses to “Casey Reas, code>conf”


  1. michael Says:

    This article on Procedural Literacy describes my experiences teaching Computation as an Expressive Medium, and, more generally, my thoughts on procedural literacy. The first iteration of this class was taught using Java; subsequent versions use Processing. I think Processing is great, both pedagogically and as a framework for doing (some forms of) software art, though it does definitely priviledge the visual.

  2. Ian Bogost Says:

    One of my Georgia Tech masters students (Michael is also on the committee), Jeff Crouse, has created a set of extensions for processing that add textual processes to its core visual processes. He calls it switchboard. Definitely worth checking out.

    One point tho: processing isn’t procedural (in the Pascal sense); it’s just simplified java, and inhererently object oriented (can import any java native classes). So I don’t understand the suggestion that one starts off with processing and moves into OOP. I suppose processing does afford simple procedural programming without the overhead of OOP, but OOP’s certainly in there.

  3. andrew Says:

    I haven’t used Processing, but I don’t make any distinction, when talking about the term “procedural”, between Pascal-like functions and object-oriented classes with methods a la Java… They’re both programming and require procedural literacy.

    Gorgeous image, btw. GTxA has a hairball.

  4. Ian Bogost Says:

    They’re both programming and require procedural literacy.

    You’re right of course. But there’s a strain of computer scientists who understand “procedural” as a programming paradigm rather than as a general term for writing processes. I’ve sometimes found it necessary to distinguish so as not to confuse OOPers who revile Pascal and related “procedural paradigm” languages.

  5. michael Says:

    Yes, whenever I give a talk to computer scientists about procedural content, I always have to be careful to say that by procedural, I mean algorithmic generation, not the programming paradigm. In the context of programming paradigms, “procedural” is not only contrasted with OOP (structural distinction), but also with functional and declarative (e.g. logical) programming (control flow distinction). So yes, though within the game design context procedural has become a synonym for algorithmic, it hasn’t within CS. With discussions of “procedural literacy” starting to appear in CS contexts, the meaning is starting to change.

    In 6310 I definitely teach objected-oriented programming in Processing (initially with students defining classes within their code, eventually with students importing external class libraries).

  6. Fox Harrell Says:

    Interesting, I have had a difficult time explaining the idea of procedural literacy to computer scientists for exactly the same reason. I think computer scientists are hardwired to be opposed to seeing “procedural” and “algorithmic” as synonymous in this sense.

    More interestingly, perhaps because they consider programming to be expert knowledge, at least one computer science professor I mentioned “procedural literacy” to did not think it was crucial for reading computational “texts” (games, applications, etc.) in the long term future. Interface and interaction conventions along with updated humanistic concerns (for example a type of semiotics that can account for dynamic computational signs) seemed much more important in this researcher’s viewpoint. I was able to convince him of the importance of a procedural literacy, but not of its importance as a central literacy by new media/interactive media/computational art practitioners.

    Have you considered Andy diSessa’s concept of computational literacy in these discussions? I am just gaining familiarity with it and he distinguishes between literacies and elucidates several pillars of a computational literacy. Being able to both produce and consume (write and read) seems to be crucial for the strongest type of literacy. The point of view of those promoting broad “procedural literacy” seem to be seeking what diSessa describes, though it is a difficult quest. Even regarding the web at this point it seems difficult to truly enable facility for both production and consumption (considering the commercial and professional trajectory of the web). Even more so, the idea of gaming literacy makes sense on one hand, but on the other most game players do not know how to, or even want to know how to, make games.

    It is interesting to compare the relative two-way literacies possible with various media. One can look at ideas such as Marc Davis’s garage cinema, or the procedural literacy described by Michael above as pushes toward two way literacies in video and computational media respectively. The challenges vary greatly for these different media and I find it interesting to ask exactly what these new literacies would entail, why they are important, and how broadly they could impact society or academia.

  7. Ian Bogost Says:

    I don’t have the time to explain it properly here, but I don’t believe that procedural literacy is equivalent with programming literacy. I’ve been arguing for a while that procedurality is a broader conceptual domain than computation (I started to make this argument in my recent book (shameless plug), but I make it more explicitly in a new one about procedural rhetoric, which should be out next year). So for me, procedural literacy and programming literacy must be distinguished. I’m strongly in favor of the latter type of literacy–an ability to read and write computational processes–but I worry greatly about equating procedurality with computation. Regarding Fox’s comparison with comptuational literacy, even this isn’t broad enough for me. Perhaps in my view, true algorithmic or computational literacy entails procedural literacy, but I don’t believe such an approach is common. I love Processing as much as anyone, but learning to make boxes jiggle and lines squiggle has little in common with understanding and translating processes in the material/conceptual world into computational media artifacts.

    This is a complex topic and I don’t feel that my comments above are doing it justice, especially since I’ve spoken and written about them in more detail elsewhere.

    Interestingly, in his GDC keynote this year Will Wright said that he’d been given a hard time for using the term procedural and asked the audience to vote by applause on a “new” name. Actually, he said his team was sick of hearing the term. The alternative options he gave were:

    parametric
    algorithmic
    generative

    Generative won by a mile, which I found interesting, since for me generativity implies a procedural system with limited user manipulation; a self-reproductive system. This is not what Wright is really interested in. I talked with some Spore folks afterwards, all of whom were confused about why Wright thought that “procedural” was overused or on the way out. They agreed that the alternatives listed above, while similar in meaning, were clearly not identical, and that the differences mattered in some material way vis-a-vis characterizing their methods and goals.

  8. andrew Says:

    Wright thought that “procedural” was overused or on the way out

    gosh, I hope not

    Not to sidetrack the emerging procedural literacy discussion, but check out more of Casey Reas’ work, from a recent Digital Art Museum show… Truly stunning.

    Over time, Reas’ beautiful creatures begin to move together when they discover they are ‘alike.’ Paths in space are explored as positions over time in relationship to other ‘vehicles’. Stimuli in the environment causes reactions among similarly configured organism systems.

    It’s very cool to think of programming autonomous distributed agents, and setting up an environment for them to behave in, to essentially paint your painting for you. (Obviously a bottom-up a-life approach, versus an more top-down AI-based approach to generativity, e.g. 1 2.)

    In the process of briefly googling around for the history of such agent techniques (e.g. “neural agents“; is this historically the most common generative visual art technique, besides fractals?), I found this *amazing* blog, generator.x — a survey of tons of very high quality generative visual art, plus a conference and exhibition, all in one. Scroll through the archives for a real visual treat!

    I really would love to spend a few days just reading up on all this, it’s so exciting and such a fertile area for exploration. (I have oil/acrylic painted a bit in the past, super-large canvases are my favorite :-)

    A post from last January, “Processing or die“, links to some discussions by artists (1 2) and on Processing’s forums including comments from Reas and Processing co-creator Ben Fry, regarding concerns about Processing’s limitations vis-a-vis its gaining popularity.

    Added to the blogroll…

  9. mark Says:

    I don’t have the time to explain it properly here, but I don’t believe that procedural literacy is equivalent with programming literacy. I’ve been arguing for a while that procedurality is a broader conceptual domain than computation…

    Obviously you can’t make much of an argument in a blog post, but I’m wondering at what level you mean this. Are you arguing that there exist processes that are not computational in one way or another (i.e. you reject computationalism as a cognitive theory), or merely that low-level computer code is not always the best level at which to understand a process?

  10. andrew Says:

    Hopefully Ian doesn’t mean people need to learn how to fill out forms in triplicate… ;-)

  11. Ian Bogost Says:

    Mark: Yes, I’m arguing that processes are not necessarily computational.

    Andrew: No, I don’t mean that. Actually, in the manuscript I just finished I go to great lengths to deflect the common notion that procedurality = bureaucracy.

  12. Fox Harrell Says:

    I agree that processes are not necessarily computational. I also reject a computationalist view of cognition.

    But what I was writing about above is what literacy regarding computational media really entails, if it is possible, and why it is considered desirable. Of course there are broader concepts than computation that are important for understanding real world processes. I appreciate the effort to try and elucidate some of these broader concepts and how they play out in the instance of computation.

    Since this conversation is becoming a bit unclear to me (defining procedural literacy or computational literacy seems a far cry from discussions of computational views of cognition to my mind), I’ll try to clarify my points.

    1) I was highlighting the cautions posted above for using the term “procedural literacy” in a computer science context without clear explanation.
    2) I was introducing to the discussion a view of computational literacy (diSessa’s) that may be related to the view of procedural literacy espoused my Michael Mateas above.
    3) I was mentioning a view of literacy that I think helps to reveal how computational literacy may differ than text based literacy or even video literacy.

    I think that the type of literacy that we are talking about here clearly is not the same as programming ability. I also think that we should be careful about what we call a “literacy” and what constitutes an important set of knowledge but not a “literacy.” The idea of a broad procedural literacy is fascinating and I would love to hear (read) more about it. Ian, your book sounds very interesting and I look forward to picking it up in the near future.

  13. mark Says:

    The relevance I saw is that saying procedural literacy and computational literacy are distinct only makes sense, at least to me, if there exist non-computational procedures. Alternately I was wondering if Ian didn’t mean that, but instead was arguing that “computational literacy” means something more narrow (like programming ability), and so was distinct from a more high-level sort of “procedural literacy”. But he clarified that his claim is the stronger one. I brought in cognitive science because Ian mentioned culture, but if computationalism as a cognitive theory is correct, then interaction between people is also understandable as computation.

    In any case, I think the view that there exist “procedures” that aren’t computation is mistaken, but I’ll wait to see Ian’s argument for it. =]

  14. Dirk Scheuring Says:

    You’re right, Mark; the term “procedural literacy”, as Michael defines it, really only makes sense to use for hypercomputationalists. I think is marks up The Great Divide between AI researchers in an interesting way. This is a divide of great practical importance to system development, because whether you view your client (user/player/interrogator/whatever) as a discrete system that typically uses a rule-based generator to produce output (= your agent’s input), as the computationalists do it, or as a continuous system that typically provides a random string (e.g. using a Zipf curve-like distribution), as the hypercomputationalists do it, makes all the difference in the architecture and design which you choose for your agent(s). If your system requirements say that you’ll have to account for truly continuous procedures as providing input, but you are limited to using a discrete system as your medium, you need a language to write your account in, and I’m hoping that such a language can be grown under the label of “procedural literacy”. For computationalists, “computational literacy” surely provides enough to work with.

    However, I’ll supend my longer argument against computationalism for a while. I think AI has enough of that right now. The beautiful thing – to me – about Algorithmic Information Theory is that, if you don’t believe that the random string is incompressible, you can just run the theory on your computer, and see for yourself. Sharing, or at least comparing the results of, executable theories is how discussions in AI should really work, in my opinion.

    I really see the current state of AI as a competition between computationalists and hypercomputationalists that will determine the theory or theories which result in the most useful and/or popular systems. Stop yakking – it’s on.

  15. nad Says:

    the problem about the word “procedural” is that it is clearly context sensitive.

    So even in CS -”prodecural programming” is not a clear cut paradigm.
    (http://en.wikipedia.org/wiki/Procedural_programming) as it seems.
    Its functional with mutation or imperative for the others…what a mess.
    So what about using the term “mathematical literacy” instead …(grin)

Powered by WordPress