In some sort of relationship to my dissertation, which explores the ideology behind codic language, I started to code. What I haven’t figured out quite yet, and what I want to explore, is what this code is. Is it software? Almost definitely not… Is it art? Well, maybe… Is it criticism? Again, maybe… Is it experimentation? Yes, well, maybe…

I’ll talk more about my particular situation below. But to zoom out, these sorts of questions apply very broadly to the humanities. The humanities of course are more than one thing, but if I might hazard a relatively common idea of what brings us together, it would be the hermeneutic method. The 2010s has seen the proliferation of various humanities “labs,” as well as software- and media-making projects amongst humanists. So much so that many have reacted with some degree of alarm, as funding is supposedly drained from other humanities-oriented activities. To what degree these other research activities were always going to be defunded is unknowable, but it is incontrovertible that funding in the humanities for a particular computer-oriented niche of creative activity has gone way up, and other research activities have not seen a proportional rise.

Doubtless several people on this forum had their feathers ruffled by a 2016 article in the LARB on “A Political History of Digital Humanities” (https://lareviewofbooks.org/article/neoliberal-tools-archives-political-history-digital-humanities/). In that article, the authors speak about the material basis of this explosion of lab-type activity, and how that basis tends to undercut precisely the critical, hermeneutic method which ought to define the humanities:

“Those who wish to acquire a sizeable grant, and who do not have site-based research needs, must develop a compelling rationale to employ graduate students. One of the simplest ways to justify the need for graduate students is to set up a named lab—a lab that requires not just funding but continual funding, and whose students can work on an evolving list of projects. In turn, applicants must explain how graduate students’ research enhances their employability. This makes Digital Humanities labs especially attractive, and makes researchers feel as if they cannot win large grants without doing Digital Humanities.”

I am one of those graduate students. And one answer to “what is all this code I’ve been writing?” is: it is the meaningless precipitate of a system that funds my otherwise prose-based research.

But if the materialist study of ideology has taught me anything, it is that meaningless precipitates don’t stay meaningless for very long. And the circumstances in which a thing is generated are rarely the determinants of the ideology which that thing ultimately expresses. So here we are. We have tons of code projects. I think it’s safe to say that, at least in our little subdiscipline of critical code studies, we have no intention of giving up on the sort of critical hermeneutics that has always characterized the humanities. If we are going to make anything of these projects, we are going to have to somehow draw our codework into a broader hermeneutic methodology. To focus all this in a single question: how can the creation of media, especially of code, be hermeneutic?

Continued...

by Margaret Rhee, John P. Bell, and Evan Buswell
feat. code from Ben Grosser

Key threads:

• Coding as Method?
• Calvinball and Coders
• Poetry as Code? Code as Poetry
• Rando by Ben Grosser (Code Critique)

We are three people who write code, in one capacity or another: Margaret Rhee, John P. Bell, and Evan Buswell. Each of us brings a different approach to coding, and code has a different relationship to each of our works. We’d like to bring out those different approaches, but also to hear from everyone else in the working group about how they code, or how they think differently about coding because of their critical approach.

We’ll each be making an individual presentation today (Monday), Tuesday, and Wednesday. So stay tuned! As a bonus, we will also have a featured code critique on Go Rando from Ben Grosser!

Below, we have a list of provocations and questions to consider throughout the week. Feel free to post in this thread anything that has to do with these questions, or with critical or creative coding more broadly.

Provocations

1. The humanities is increasingly focusing on making and doing, to supplement its previous focuses on understanding and interpreting.
2. Critically writing code is the other side of critically reading code, and we want to foster a healthy relationship between these two approaches to code and coding.
3. How is code poetry? How is poetry code?
4. Do we build bridges across code approaches?
5. Where does utility end and play begin? Can you use the same critical framework to think about both independently?
6. What is the relationship between Critical Code Studies and writing code?

In Ben's words:

Facebook’s “reactions” let you quickly express how you feel about a link, photo, or status. While such data might be helpful for your friends, these recorded feelings also enable increased surveillance, government profiling, more targeted advertising, and emotional manipulation. Go Rando is a web browser extension that obfuscates how you feel. Every time you click “Like”, Go Rando randomly chooses one of the six Facebook “reactions” for you. Over time you'll appear to Facebook’s algorithms as someone whose feelings are perfectly balanced—as someone who feels Angry as much as Haha or Sad as much as Love. You can still choose a specific reaction if you want to, but even that choice will be obscured by an emotion profile increasingly filled with noise. In other words, Facebook won’t know if your reaction was genuine or not. Want to see what Facebook feels like when your emotions are obscured? Then Go Rando!

Consider Rando in the context of the Week 2 theme.

Language: Javascript
Author: Ben Grosser

// ==UserScript==
// @name Go Rando
// @version 1.0.0
// @author Benjamin Grosser
// @namespace com.bengrosser.gorando
// @description Obfuscates your feelings on Facebook.

// @updateURL http://bengrosser.com/share/gr/go-rando.meta.js
// @downloadURL https://bengrosser.com/share/gr/go-rando.user.js
//
// @match *://*.facebook.com/*
// @include *://*.facebook.com/*
// @exclude *://*.facebook.com/ai.php*
// @exclude *://*.facebook.com/ajax/*
// @exclude *://*.facebook.com/dialog/*
// @exclude *://*.facebook.com/connect/*
// @exclude *://*.facebook.com/plugins/*
// @exclude *://*.facebook.com/xti.php*
//
// @icon http://bengrosser.com/share/gr/go-rando-logo-256.png
//
// ==/UserScript==// -----------------------------------------


// ******************************************
//
// Ben Grosser
//
// Go Rando
// 2017
// web browser extension
//
// (Started March, 2016 -- Released February, 2017)
//
// Premiere Exhibition:
// Blinding Pleasures
// Arebyte Gallery
// London, UK
// 10 Feb - 18 Mar, 2017
//
// Obfuscates your feelings on Facebook
// http://bengrosser.com/projects/go-rando/
//
// Thanks to my Beta Test Team!!
// --Janelle Gunther
// --Owen Mundy
// --Raphaël Duracell
//
// Thanks to Sebastian Frith for his Illustrator prowess!
//
// Big thanks to Kate McDowell, who suggested "Rando" as part 
// of the title!
//
// And special thanks to Filippo Lorenzin, curator of the 
// Blinding Pleasures exhibition, for all his help and support 
// for this work!
//
//
//
// ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⢀⠠⠨⢀⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠐⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⢈⠀⠀⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠠⠠⢙⣿⣿⣿⣿⣿⣿⢉⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠠⢐⣿⠀⠀⣿⣿⣿⣿⣿⢐⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠁⡟⣿⣿⠠⠠⠠⠠⠀⠀⠀⠀
// ⠀⠀⠀⠈⠠⢘⣿⣿⣿⣿⣿⣿⣿⣿⢲⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠁⣿⣿⣿⠀⠀⠀⣿⢐⠠⠠⠠⠠⠀⠀⠀
// ⠀⠀⢀⠠⠠⠠⠠⢰⣿⠀⠀⠀⠀⠀⠀⡓⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⣿⣿⠀⠀⠀⣿⣿⣿⢢⠠⠠⠠⠠⠠⠠⠠⠀⠀
// ⠀⠀⠠⠠⠠⠠⠠⣏⣿⠀⠀⠀⠀⠀⠀⣿⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠫⣿⣿⣿⠀⠀⠀⣿⣿⣿⢈⢀⢀⠠⠠⠠⠀⠀
// ⠀⠠⠠⠠⠠⠠⢘⡍⣿⠀⠀⠀⠀⠀⣿⢉⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⢐⡍⣿⣿⣿⠀⣿⢰⠈⠈⠐⠠⠠⠠⠀
//  ⠠⠠⠠⠠⠠⢈⠠⣆⣿⠀⠀⣿⣿⢘⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⢈⠠⠠⠠⠠⠁⣿⣿⣿⣿⠁⢈⠁⠠⠈⠈⠠⠠⠠⠠⢀
//  ⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⠨⢐⠰⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⢘⠠⠠⠠⠠⠹⣿⠀⠀⠀⠀⣿⢍⠠⢰⣿⣿⠰⢘⠠⠠⠰
// ⠀⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⢈⢈⠠⠨⢈⠠⠠⠠⠠⠠⠠⠠⠠⢐⠠⠠⠠⠠⢈⡃⠀⠀⠀⠀⠀⠀⣿⣿⠀⠀⣿⢬⠰⠠⠠⠀
// ⠀⠠⠠⠠⠠⠠⠠⠠⠠⠠⠠⢈⢈⢈⠂⠠⠠⠠⠠⠠⠠⠠⠠⢈⠨⢼⣿⣿⠀⣿⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⠺⠰⢈⠠⠠⠠⠀
// ⠀⠀⠠⠠⠠⠠⠠⠠⠑⢩⢙⢩⣈⣈⢙⢙⢙⢙⢙⢙⢙⢙⢙⢈⠠⢨⣿⣿⣿⣿⣿⣿⠀⠀⠀⠀⣿⠨⢈⢐⠘⢈⠠⠠⠠⠀⠀
// ⠀⠀⠈⠠⠠⠠⠠⡤⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⠠⠠⠠⠠⢘⢈⠠⠙⣿⣿⣿⣿⢘⠠⠠⠠⠠⠠⠠⠠⢀⠀⠀
// ⠀⠀⠀⠀⠠⠠⠠⢠⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⠿⢈⠠⠠⢈⠨⠠⠠⠹⣿⠓⠠⠠⠠⠠⢀⠀⠀⠀
// ⠀⠀⠀⠀⠠⠠⠠⠠⢘⣿⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⣿⣍⠠⠠⠠⠠⠽⣿⣿⣿⢑⠠⠠⠠⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠠⠠⠠⠠⠘⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⢌⢘⠠⠠⡡⣿⣿⢘⠠⠠⠠⡇⣿⣿⣿⣿⣿⢴⠀⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠀⠠⠠⠠⠠⠩⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡈⠠⠠⠠⠠⠠⠠⠠⠠⠠⣠⣿⣿⣿⣿⣿⣿⣿⠀⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⠠⠠⠠⠋⣿⣿⣿⣿⣿⣿⣿⣿⡈⠠⠠⠠⠠⠠⠠⠠⠠⠙⣿⣿⣿⣿⣿⣿⣿⣿⢰⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⠠⢀⠠⠉⢔⠾⡓⡖⠨⠠⠠⠠⠠⠠⠠⠠⠠⠠⣿⣿⣿⣿⣿⣿⣿⣿⢈⠀⠀⠀⠀⠀
// ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⠀⠀⠀⠀⠀⠨⣞⣏⢷⠀⠀⠀⠀⠀⠀⠀⠀⠀
//
//
// ************************************************************


var j;
var IS_SAFARI_OR_FIREFOX_ADDON = true;
var LIKE_BLOCK_PARENT = '._khz';
var VERSION_NUMBER = '1.0.0';
var attaching = false;
var LANG = "en";

var reactionLabelsEN = ["Like","Love","Haha","Wow","Sad","Angry"];
var reactionLabelsFR = ["J’aime","J’adore","Haha","Wouah","Triste","Grrr"];
var reactionLabelsDE = ["Gefällt mir","Love","Haha","Wow","Traurig","Wütend"];
var reactionLabelsES = ["Me gusta","Me encanta","Me divierte","Me asombra","Me entristece","Me enoja"];
var reactionLabelsPT = ["Curtir","Amei","Haha","Uau","Triste","Grr"];
var reactionLabelsIT = ["Mi piace","Love","Ahah","Wow","Sigh","Grrr"];

var pickingTextEN = "Picking...";
var pickingTextFR = "Sélection...";
var pickingTextDE = "Auswählen...";
var pickingTextES = "Selección...";
var pickingTextPT = "Seleção...";
var pickingTextIT = "Selezione...";


function main() {
    var startURL = window.location.href;

    // Firefox/Safari Extensions/Userscripts don't allow 
    // excludes in the URL match, so we do it here.
    if(IS_SAFARI_OR_FIREFOX_ADDON) {
        if(startURL.contains("ai.php") || 
           startURL.contains("/ajax/") ||
           startURL.contains("/dialog/") ||
           startURL.contains("/connect/") ||
           startURL.contains("/plugins/") ||
           startURL.contains("/xti.php")
           ) return; 
    }

    // console reporting
    console.log("Go Rando "+VERSION_NUMBER);
    console.log("    --> "+startURL);

    // setup jQuery on j to avoid any possible conflicts
    j = jQuery.noConflict();

    // determine language. 
    LANG = j('html').attr('lang');

    if(!(LANG == "en" || LANG == "fr" || LANG == "de" ||
         LANG == "es" || LANG == "pt" || LANG == "it")) {
        console.log("Go Rando --> unsupported language detected ("+LANG+")"); 
        console.log("Go Rando --> defaulting to English");
        LANG = "en";
    }

    // monitor the DOM for insertions
    var watchNode = document.querySelector('body, ._5pcb');

    var observer = new MutationObserver(function(mutations) {
        mutations.forEach(function(mutation) {
            if(mutation.type == "childList" && !attaching) {
                attaching = true;

                for(var i = 0; i < 2000; i+=250) {
                    delayedSetup(i);
                }
            }
        });
    });

    observer.observe(watchNode, { childList: true } );

    // run a few times for each insertion to catch 
    // slower-loading nodes
    function delayedSetup(t) {
        setTimeout(function() {
            setupReactionsBlock(j(LIKE_BLOCK_PARENT));
            if(t == 1750) attaching = false;
        }, t);
    }
}

// find the correct Like buttons and attach an obfuscator
function setupReactionsBlock(n) {
    n.
        not('.reactionObfuscated').
        addClass('reactionObfuscated').
        find('.UFILikeLink').
        each(function() {
            attachReactionObfuscator(j(this));
        }
    );
}

// binds a function to every Like button so that a click
// triggers an obufscation rather than regular "Like"
function attachReactionObfuscator(n) {
    var reactionLabels;
    var likeText;
    var pickingText;

    if(LANG == "en") {
        reactionLabels = reactionLabelsEN;
        pickingText = pickingTextEN;
    } else if(LANG == "fr") {
        reactionLabels = reactionLabelsFR;
        pickingText = pickingTextFR;
    } else if(LANG == "de") {
        reactionLabels = reactionLabelsDE;
        pickingText = pickingTextDE;
    } else if(LANG == "es") {
        reactionLabels = reactionLabelsES;
        pickingText = pickingTextES;
    } else if(LANG == "pt") {
        reactionLabels = reactionLabelsPT;
        pickingText = pickingTextPT;
    } else if(LANG == "it") {
        reactionLabels = reactionLabelsIT;
        pickingText = pickingTextIT;
    }

    likeText = reactionLabels[0];

    n.click(function(e) { 

        var likeON = false;
        if(n.hasClass('UFILinkBright')) likeON = true; 

        if(!likeON) {

            var pick = Math.floor(Math.random() * reactionLabels.length);
            var r = reactionLabels[pick];
            var lp = n.parent();

            function setThinking(jn) {
                j(jn).hide();
                return j(jn)
                        .parent()
                        .prepend("<a class='gr_picking'>"+pickingText+"</a>")
                        .promise();
            }

            setThinking(j(this)).done(function() {
                setTimeout(function() {
                    var t = lp.find('._iuw[aria-label="'+r+'"]');

                    if(t.length) {
                        if(r != likeText) t.click();
                        lp.find('.UFILikeLink').show();
                        lp.find('.gr_picking').remove();
                    } 
                    else {
                        lp.find('.UFILikeLink').show();
                        lp.find('.gr_picking').remove();
                    }
                }, 500);
            });
        }
    });
}


//
// ALL UTILITY BELOW HERE
//

// cleaner syntax than match()
String.prototype.contains = function(it) { return this.indexOf(it) != -1; };


// pasted jQuery 3.1.1 slim minified from 
// https://code.jquery.com/jquery-3.1.1.slim.min.js

See full code here.

Some starter questions:

-How does the code express Grosser's critical intervention?
-How does this code affect the way we see Facebook?
-In what ways does this code disrupt Facebook's functioning, serve or enhance it?
- Where do you sense Grosser's play and irony in the code?

-- Alan Turing

Dear All,

Thanks to Evan and John for starting us off, and to everyone for your insights, and questions.

I want to begin by a small note on digital communication, intimacy, and ephemera. I've been moved by how intellectual, creative, and political occurs online, the poetics of it, which I think lends itself to the ephemeral nature of these conversations that spark ideas, and movements.

Forums like this, and others that we find at HASTAC, and --empyre-- for example, have facilitated new ways of thinking, engaging on digital topics. I find it important to think about the particular "digital landscape" in which we form these discussions, especially since much of the intersections on creative and critical code tends to happen in these digital, avant, moonlighting spaces, where transgression and mutations are encouraged, and ignited.

For my part, I want to share some ideas and examples of the intersection between code and poetry that have come up from the past year, and share from my current book of poetry which engaged with code and the robot. So primarily I will discuss code through my work as a poet. It has been an ongoing investigation of this idea of invented languages.

The question that outlines my poetry collection Love, Robot, which is a science fiction poetry collection of a world that robots and humans fall in and out of love, includes the intersection of code and poetry.

The following below is simply a series of gestures, and I look forward to the conversation.

Two articles I recently wrote from seemingly disparate forums may help articulate some of my current ideas and questions:

Two seemingly disparate publications, the Association for Computing Machinery graduate student magazine XRDS, and Poets & Writers, the publication for creative writers.

In the first article for ACM, I primarily address graduate students in computer science and ask to think about the humanities and poetry in their work. I also share how the poetics is an ongoing response to Alan Turing's "Computer Machinery and Intelligence:" "Can Machines Think?" and "I could never write poetry." I think these two quotes from Turing helps us think about the connections/transgressions/separations of code and poetics in important ways.

The article for Poets and Writers articulate how research can help the poem's formation, and I draw on my research process for writing the poetry. Both articulations, I hoped, would help bridge the intersections of poetics and technology, or code.

Another quote from William Carlos Williams to think with: "A poem is a small (or large) machine made of words."

Article Links:

https://dl.acm.org/citation.cfm?id=3155126&dl=ACM&coll=DL

https://www.pw.org/writers_recommend/margaret_rhee

I want to also gesture to Helen Vender's writing on poets, and particular "Poet's Thinking:"

"In short, the relation of poetry to thought is an uneasy one. Some law
other than the conduct of an argument is always governing a poem, even
when the poem purports to be relating the undolfing of thought. On the
other hand, even when a poem seems to be spontaneous outburst of
feeling, it is being directed, as a feat of ordered language, but
something one can only call thought."

Here, Vendler is interested in how poets think through their poetry, by
grouping together four poets-- Dickinson, Pope, Whitman, and Yeats--she
argues how poets embody a process of thinking, that is original, and
unique to the poet.

As Vendler writes, "My question--by what means does a poet reproduce an
individual and characteristic process of thinking? -- can be addressed
to any work."

Question: How can we think of the "codes" in poetics?

When I was a graduate student, I was researching the cultural history of robotics quite heavily, and turned to robotics code. I found code beautiful. As I was writing my collection, the idea of logics and pattern from Vender, along with the aesthetics of code inspired me to write codes in my poetic work. Largely these codes, go alongside the narrative poems I wrote. Later, I draw upon chatscripts as poems.

For example, here is the narrative poem Beam, Robot:

Then the algorithm that is included in the book, but not in the magazine publication:

Other provocations and examples. I will turn humbly to Mark Marino, who has always been an inspiring model of the intersection of the humanities/science, through his creative and critical code work. We recently had a reading at the Poetic Research Bureau in Los Angeles where Mark translated the code in my poem "Sleep, Robot," "Algorithm, Sleep":

Algorithm Sleep

1. config = source
2. loop
3. loop
4. if (config == goal) return goal reached;
5. if (config ==) stay
6. dream 
7. ```


------------------------------------------------------------
By Mark Marino: 

```javascript
// Javascript second try
function cycle () {   // or should I call it -- preoccupy
    while (config != goal)
     stay();
    return goal reached;
    }
var config = source;
var i=0;
while (i<=2) 
     {i++;};
    cycle(); 
dream ();

Language: Chicken

chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken chicken
chicken chicken chicken chicken chicken chicken

Input Dream

Language: HODOR
hodor hodor hodor hodor hodor hodor hodor hodor hodor hodor hodor 

Input Dream

I also want to ask about the tangible poetics of coding? Outside the GUI and into the TUI.

The poetry of soldering?

I want to end these gestures with a note on community and writing prompts, so for those who want to engage can create their own code poems. Oftentimes, there is a romance to communities that can fail, and often fails. But I am buoyed by the possibility of conversation, as ephemeral it can be.

We must constantly strive towards it.

Writing Prompts:

• Drawing from the Marino Method of Poetics, translate a poem (or code) into 3 programming languages.
• Write your own poem about robots and humans interactions, write a narrative poem, then translate the narrative into code
• Pick a newspaper article about code (or any topic), and create an erasure. Erase words until you have a poem left. What do you have left? Create another iteration of the poem if you like.

For those who, like me, grew up looking forward to my daily Calvin and Hobbes strip, Calvinball is a pure expression of imagination, creativity, and six-year-old innocent fun. Calvinball is a game that is made up as you play it and the only rule is that you can never play it the same way twice. For the purposes of this CCSWG I’m going to rephrase that rule and possibly ruin some programmers’ childhoods: when playing Calvinball, Don’t Repeat Yourself.

DRY

Depending on which programmer you’re talking to, Don’t Repeat Yourself (DRY) might be a good guideline, a Platonic ideal to be sought after, or a form of viral pedantry that gets in the way of writing software. It’s the idea that, particularly in object-oriented languages, you never want multiple pieces of code that fulfill the same function. As the argument goes, duplicating code introduces more potential for errors that are harder to discover and diagnose, makes a codebase harder to maintain, and generally complicates everything. There are any number of ways to apply this principle in practice (I like the three strikes rule in many contexts) but it is almost exclusively supported by utilitarian/functional arguments in computer science texts and forum discussions.

What’s My Motivation?

When discussing DRY, what I think is often left unsaid is simply that programmers like playing Calvinball. They enjoy creating new mechanisms and structures more than they enjoy repetition; a canonical joke is that a programmer would rather spend an hour writing a script than ten minutes doing a repetitive task by hand. DRY is a principle that wraps creative urges–play, rather than work–in a cloak of functional respectability†. This is not to say that the DRY principle, or the functional arguments behind it, are illegitimate. It is true that DRY can simplify maintenance, among other things. However, when thinking critically about code and examining the motivations of a programmer at the granular level of individual statements, motives of utility and creativity can be hard to tease apart.

For this discussion, I’m going to split the DRY mindset into two concepts based on what drives a programmer to think and work in DRY terms:

• Calvinball-DRY – The creative play motivation
• CS-DRY – The utilitarian motivation

In doing so, though, it’s important to keep in mind that the two can be very difficult to separate in practice. The two motivations may very well produce the same DRY code that leaves no way for a later reader to tell them apart. But in other cases a DRY process–from the programmer’s perspective–may not lead to DRY code. For example, I wrote a piece called Asterisk Painting for an art installation several years ago. The complete Processing code is below:

/**
Asterisk Painting is programmed to create a series of asterisks by repeatedly printing the number of 
milliseconds that have passed since the painting started. If left to run by itself it will do so; however, 
when started on a real system, delays external to my artwork may make the asterisks look more like 
spots and the painting may resemble the work of certain other overly-litigious artists. 
**/

//int xDim = 1920;
//int yDim = 1080;
int xDim = 1440;
int yDim = 900;

PFont theFont;
float timer=0;
float speed=100;
float maxSentences = 77;
float sentences = 0;
float[] xPos = {1,2,3,4,5,6,7,8};
float[] yPos = {1,2,3,4,5};
int xCtr = 0;
int yCtr = 0;
int waitTime = 10000;
int itr = 0;
int milliStart = 0;
PImage sig;

void setup(){
  background(255);
  noCursor();
  size(xDim, yDim);
  sig = loadImage("signature-small.jpg");
  image(sig, xDim-92, yDim-50, 82, 40);
  theFont = loadFont("Luvia-48.vlw");
  for(int i=0; i<xPos.length; i++) xPos[i] = xPos[i] * (xDim / (xPos.length+1));
  for(int i=0; i<yPos.length; i++) yPos[i] = yPos[i] * (yDim / (yPos.length+1));
  fill(0);
  textAlign(LEFT, CENTER);
  text(itr, 10, yDim-30);
  fill(random(0,255),random(0,255),random(0,255));    
}

void draw(){
  int currentMillis = millis() - milliStart;
  if(currentMillis > timer){
    pushMatrix();
    translate(xPos[xCtr], yPos[yCtr]);
    rotate(radians((float)(360/8)* (float)(millis()/speed)));
    timer = currentMillis + speed;
    text(nf(currentMillis, 6), 3, 0);        
    sentences++;
    if(sentences >= maxSentences){
      xCtr++;
      if(xCtr >= xPos.length) {
        xCtr = 0;
        yCtr++;
        if(yCtr >= yPos.length){
          saveFrame();          
          yCtr = 0;
          background(255);
          itr++;
          popMatrix();
          fill(0);
          text(itr, 10, yDim-30);
          image(sig, xDim-92, yDim-50, 82, 40);
          int wait = millis() + waitTime;
          while(millis() < wait){}
          milliStart = millis();
          timer = speed;
          pushMatrix(); 
        }
      }
      sentences = 0;
      fill(random(0,255),random(0,255),random(0,255));
    }
    popMatrix();
  }
}

The result looks like this:

If you compare the code to the output then a couple of variable names seem incongruous: sentences and maxSentences. There are, in fact, no sentences in the final output. The sentences variable is actually counting the number of times that the milliseconds counter has been printed to the screen in any given asterisk. When sentences goes above maxSentences, the code moves output to a new asterisk.

The reason for those names has nothing to do with anything in this piece of code. They are there because Asterisk Painting started life as a copy/pasted script from another piece I was working on at the time, Finite Monkeys. That piece searched the Twitter firehose for the word ‘love’ every thirty seconds and compared the results to Shakespeare’s Sonnet 18 (“Shall I compare thee to a summer’s day...”), displaying the most similar tweets on screen. In that code, sentences and maxSentences were used to count target tweets and cap them at a certain number for performance reasons. The two variable names are just the breadcrumbs left behind that provide evidence of duplicated and modified code.

When DRY Isn’t DRY

Copy/paste workflows are generally considered the opposite of DRY–they duplicate code that, under DRY principles, should be maintained in one place and invoked elsewhere. This code isn’t CS-DRY. However, it is Calvinball-DRY. Even though my code repeated itself, I, the programmer, didn’t have to repeat myself. Copy/paste coding separates the creative personal motivations for DRY from the utilitarian public justifications.

This is not to say there is a 1:1 correlation between copy/paste code and creative motivations. However, finding code that’s been copy/pasted does provide insight into the programmer. Zooming out a bit, the prevalence and acceptance of copy/pasted code across the industry also suggests something about programmers as group. Many of us are professional Calvinball players, motivated as much or more by creative exploration as by trying to accomplish a task.

When Creative Isn’t Creative

There’s a caveat to the idea of creativity in both Calvinball and Calvinball-DRY: it’s narrowly scoped. Calvinball only exists inside Calvin’s head. Despite a couple of attempts to get other people to play it with him, nobody really does so consistently (the imaginary Hobbes aside). The idea of other people playing Calvinball introduces a new wrinkle though: what does it mean that “the only rule of Calvinball is that you can’t play it the same way twice” if there are multiple players? If I create a rule in my Calvinball game, does that exclude you from creating that same rule in your separate Calvinball game? Is creativity global or local?

For Calvin, who couldn’t care less about the rest of the world as long as he’s having fun, the answer is probably that creativity is local. I’d suggest the same is true for many programmers: if we suppose that Calvinball-DRY is a desire to scratch a creative itch then it shouldn’t matter whether someone else has already solved a problem in the same way‡. If that other solution isn’t known to the programmer then writing it represents personal novelty and answers a creative urge. Locally creative is good enough, even if an outside observer wouldn’t call a particular bit of code novel or creative.

Finding the Breadcrumbs

I don’t think the idea that programmers are partially driven by a desire for creative play will be particularly controversial among this group of participants. However, my goal in starting this discussion is to look for signs of creative motivations even if the code itself is boring, functional, or straightforward. What code have you seen that suggests a programmer is playing even when the goal of the program is functional? What are the indications that getting into a programmer’s head will lead to a piece of code being more appropriately read through a creative lens than a functional one, and when (if ever) are the two separable? After all:

† Functionality being rather easier to justify to middle management than creativity, of course.
‡ Some coders treat code more as a performative medium; this probably wouldn't apply to them.

#include <iostream>
int main()
{
    int i;
    while(i == 0) {
        std::cout <<  i ;
    }
    std::cout << "RUN!" << std::endl;
    return 0;
}

Explanation
AI Prison is artwork that engages, seriously and humorously, with ontological and philosophical issues surrounding AI. In that respect the work’s premises pertains to the possibility, or better impossibility, for a system to independently self-organize and self-evolve its own physical memory paths, let alone to be intelligent, conscious or creative. Trapped by a series of human-built ‘chains’ (virtual memory, memory management units, os etc.), computers’ softwares are ‘locked’ within themselves and forbidden the possibility to evolve and act intentionally. With these ‘chains’ in place, it does not count the complexity of the computational methods deployed (see any AI technical literature in that regard) since the chains are beyond the control of the program itself and unbreakable by it (or overlooked by the programmer).
Thus, simplicity will suffice here.

Description of how the code operates:
The aesthetics are generated by the result of a C++ program that repeatedly test for evidence of intentionality. Evidences that, so far, have been quite predictably refuted. Because “i” is not initialised, VM and MMU (controlled by the OS and not the program) are zeroing the memory allocated to the program for us and automatically. Thus an endless stream of zeros are printed to the terminal. Note that in Java, for example, not initialising variables will produce an error and fail to compile.
Can then AI break chains without even being aware of their existence? Well, if it does...RUN!!!...the software has done something it wasn't designed for (AI dystopia)

Commentary
The piece is of course ironic and it serves as a defense against a spreading epistemological positivism that is always more influencing media/digital arts.
Whether we believe or not that science can one day provide us with computers that can mimic human behaviour, we, as people engaging in art practises, should be, probably more than anyone else, very careful in the dealing of such topic especially when ideas such as artificial intelligence (AI) and creativity or consciousness are presented in the same context. Beyond sci-fi plots, the concerned scientific and aesthetic literature too often offers text in which computer programs generating art are addressed as creative entities. This is, in my opinion, a cultural trap caused by a wealth of concomitant factors, from sociological, psychological, historical to philosophical and all more or less connected to long lasting tradition of positivist attitude in relation to knowledge.

It is not my intention to re-iterate here the many historical and philosophical arguments presented in favour and against the feasibility of intelligent machines. Nor it is my intention to suggest that much of the work done in artificial intelligence and art is oblivious of such literature. Nor that many of these works are built from a genuine belief in computer’s ability to think creatively or helping us to dream of a distant future. If anything, my intention is instead to reflect on the limitations that our reality, in fact a heavily technologically mediated reality, imposes on our dreams.

Questions
Where, and how, does code' syntax start becoming, or it is forbidden to become, and intentional act of artistic expression (semantic?) for the computer? (or for the human if you wish... an equally interesting question)

I hope you will welcome this proposal.
Looking forward to hear form you.
Kind Regards
Giuseppe Torre

Details of the work
A video of its first prototype is available here:

The work has been discussed, briefly, in the following article:
Torre, G. (2017), `Expectations versus Reality of Artificial Intelligence: using Art to Reflect on and Discuss some of the Ontological Issues.', Leonardo Art Journal - MIT.

The artwork is now part of the permanent collection of the BLITZ Contemporary Art Gallery in Malta