Chris Lindgren, PhD

Some thought-sketches. Home || @lndgrn || Archive

[softclindgren]

#4C17 Inaugural SIG on the Writing and Rhetorics of Code (SIGWROC)

Sign up to attend or for the future newsletter

For any interested parties out there, feel free to sign up (outbound Google Doc link) to attend the inaugural SIGWROC meeting at the 4Cs conference this coming March 2017. If you cannot attend, feel free to also leave your name and email address and mark that you would like to receive the future SIGWROC newsletter.

Please share widely!

[softclindgren]

A tribute to Seymour Papert

Developing a discourse is at the heart of developing a culture, and a more textured and knowledgable discourse about Logo contributes to the 'Logo culture,' the 'computer culture,' and to the 'learning culture' in its broadest sense. It sets the cultural context for personal learning. —Seymour Papert (1987, p. 23).

Today, I learned that Seymour Papert, a brilliant educator and researcher, has passed away. His work with kids and computing remains ahead of his time, and his pedagogies and philosophies surrounding computer programming and learning have yet to be fully embraced and implemented by the greater social push for coding as a mass literacy. Personally, he helped me become a better literacy researcher, thinker, and educator.

Much of my research and teaching sets out to refute deterministic "Great Leap" theories of literacy (Ong 1958; Havelock 1963; Goody & Watt 1968). Writing, and I argue writing code, are practices that are always situated and, as my mentor, Christina Haas (1996), notes, "deeply contextualized" (p. 19). Accordingly, I understand that any claims about the medium's affect on individual and cultural literacy practices must account for multiple factors that stimulate, support, or impede cultural literacy practices.

Papert's theories of programming practices and learning allies with this practice account of literacy: that individuals within a culture appropriate and used LOGO in distinct ways. In the 1980s, Papert (1987) responded to the wave of educational psychology research projects that tested for the effect of LOGO on learning. Such research agendas, he argued, adhered to a generalized notion of programming not unlike the outmoded "Great Leap" theories of literacy studies (Ong 1958; Havelock 1963; Goody & Watt 1968). He argued:

... there is no such thing as 'programming-in-general.' These children are not given programming. They are given Logo. But there is no such thing as 'Logo-in-general' either. The children encounter Logo in a particular way, in a particular relationship to other people, teachers, peer mentors, and friends. They don't encounter a thing, they encounter a culture. (p. 27)

In short, Papert helped me see how there is no big "C" computation, just as there is no big "L" literacy. The representational systems used to write code are not ahistorical, because people and their tools carry their value systems and knoweldge with them. Papert helped me use my research to temper the "code year" and "program or be programmed" crisis rhetoric surrounding learning to code. He helped and is helping me bridge disciplinary boundaries between Computer Science, Human Computer Interaction, and Writing Studies.

Thank you, Dr. Papert!

[softclindgren]

Source: penjee.com

[dataviz-parsons]

Phone Usage

by Peiying Feng and Jessie Contour

A data vis sculpture comparing phone usage of the authors for two weeks. In Cathy’s words: “Mine is on the left with the volume buttons, Jessie’s is the right with the power button. All I can say is that she picks up her phone a lot a lot! But I’m definitely not one to talk, since I spend waaaaay more time on my phone than she does. (I was reading the Brilliance Trilogy by Marcus Sakey on my phone the past two weeks!)”

[softclindgren]

Thought-sketch: Unearthing the ‘real world’ soundbite

Lately, I’ve been asked a lot about what I do exactly. I’ve found that when I respond to this question by saying that I’m (hopefully) on my way to becoming a professor of rhetoric and writing it elicits numerous kinds of responses.

In this post, I wanted to respond to one typical soundbite that I hear often from many – not all – but many folks who I talk to about the university. The soundbite on the hotseat: the “real world”.

Let me respond to that soundbite through a quick tour of my teaching.

For some of you who think that professors aren’t grounded or that we do not teach students “real world” skills, I say nay. Not to say that the educational experiences are always attuned to every students direct needs, but such an educational experience isn't specific to the university. (Another post should discuss my professional experiences with learning on-the-job prior to grad school, because it sure wasn't always applicable!)

But, I digress. Back to my thoughts on teaching and the 'real world'.

Cultural anthropologist Jean Lave once said that “We are always learning what we are already doing.” (FTR, another of my favorite cultural-cognitive anthropologists, Edwin Hutchins, has argued something very similar.) She is arguing that we move forward by learning backwards and that learning and doing go together with our everyday experiences. Learning never stops, because people and their everyday activities, experiences, and desires are many. She also notes how such learning processes are usually conducted transparently. We humans are just good at picking skills up without realizing how. Because of this fact, I try to help my students learn about learning processes: how we learn. That way, they can see how individuals' knowledge and communication forms are always connected to historical experiences with communities, their tools, and their skills.

For example, I have taught and trained students how to write technical content for the web, and I have done so through a focus on the humanities, people-oriented, cultural-based dimensions of such skills—not just skills for skills sake.

I have my students read the specifications for HTML, DITA, and CSS standards, but also conduct research into a particular web component, so they can truly see how people develop tech through an assembling of standards bodies and communities. I show them how the most mundane, transparent parts of the web are its most richly complex parts—riddled with issues of bias and power and consequences behind decisions of its development.

I’ve seen how students learn how and where to find and learn even more about such skills and social issues linked to it, if they so choose. To me, that’s a success. That’s a well-grounded, real-world-ready person. What isn’t a success to me? When a student leaves my classroom thinking there’s the way to communicate or use or develop a tool, instead of substantively multiple ways based on the audience(s) in mind.

Doesn’t that seem much more of a grounded, real-world approach to communication and tool-use, rather than some universalized, abstracted, a-historical one? For me, the latter is always buried in that “real-world” soundbite, and my teaching tries to help unearth it.

Maybe I’ll make this post into a series and talk about how I also conduct research and hope to teach research methods and methodologies courses that are far from the “real world” too.

For now, back to transcribing my research data.

[softclindgren]

“We are always learning what we are already doing. ... [begins to talk about her field of related critical ethnographers] We're a bunch of critical contrarians who explore learning as embodied practice; refuse to separate knowledge from processes of knowledge production from processes of producing knowledgably skilled practitioners. And we think that all of these relations are made in the political economic and historic relations in which they are a part. That's a tall order. If you do not treat apprenticeship as a thing in itself nor learning as a thing in itself then how do you go about inquiring into that?”

I love Jean Lave's work and wish I had a methods/methodologies course that took up her work.

[softclindgren]

“Auto-Interviews”

Preamble

This post is a jotting down of some happenings/doings in a rhetoric course that I am teaching this Spring 2016 semester. The course is an upper-division undergraduate course called "Rhetoric, Technology, and the Internet". In the first 6 weeks of the course, we read and wrote our way through a small body of multi-disciplinary scholarship in rhetoric and society and technology studies. For about 3-4 weeks thereafter, we read and wrote our through auto-ethnographic and grounded theory research scholarship. All of this work was meant to help me help students develop research problems surrounding their "rhetorical experience" with a particular everyday technology in their lives. From there, they conduct an auto-ethnographic study of such a "rhetorical experience" with the aims of defining this relationship through their qualitative study.

On Auto-Interviews

Students have been collecting qual data (fieldnotes, artifacts, etc.) and writing conceptual memos for about 2-3 weeks now. During this week, I am having them draft, develop, and conduct an "auto-interview," wherein they interview themselves to elicit some of the tacit things they've already gleaned in/through their research thus far. I wanted the students to utilize an ethnographic method to help them tease out some more details about their developing substantive definitions of rhetorical experiences. Enter interviewing.

During Monday's class, I provided a short lecture on ethnographic interviewing; mainly pulled from Spradley (1979). I discussed what interview data can provide researchers, and then I defined descriptive and structural questions a la Spradley. I added rhetorical questions—ones that they have to answer! Along the way, I tried to provide some examples of each. Finally, I had them take 15 minutes to draft a mix of these questions.

For today's class (on Wed.), I am having them take 5 minutes to write out their research problem and then their list of these types of questions by hand on paper. Then, at their tables, (where their peers already have conducted peer review and had multiple discussions surrounding their projects already), students will have 5-7 minutes each to help each other piece together and cut out questions for them to answer over the remainder of the week (due by the next class on Monday). In short, students will help each other develop a good set of questions for them to develop a more systematic way intoexploring some dimension of their "auto-rhetorical" study about their rhetorical relationship with some technology.

[esoteric-codes]

A look at Algorithmic Theatre with “Yesterday, Tomorrow” creator Annie Dorsen

Photo by Maria Baranova

This week we break from esoteric programming for a look at how code and human expression interact in theatre. In Annie Dorsen’s Yesterday Tomorrow, three performers (Hai-Ting Chinn, Jeffrey Gavett, and Natalie Raybould) sing Paul McCartney’s “Yesterday” repeatedly while it transforms in small incremets over an hour – according to a computer-generated score – to eventually arrive at “Tomorrow” from the musical Annie. In the middle of the transformation, the lines of music take on “an eerie liturgical quality, as if each singer were performing an individual Gregorian chant” according to the New York Times. In 2012, Dorsen wrote On Algorithmic Theatre, describing modes of algorithmic practice that challenge basic notions of what theatre is and how it functions.

Pierre Godard wrote the code for Yesterday Tomorrow and provides technical info about the process. He has created or contributed to a number of performative algorithmic works, including the recent dance performance For Claude Shannon.

» How did you first arrive at the concept of Algorithmic Theatre?

Annie: I’d already made Hello Hi There, or rather I was in the late stages of that process, when I invented that term. I’d started getting a sense that I was on the edge of something much larger than any one project, and that could perhaps initiate an entirely new way of making theatre. The beginning of Hello Hi There was actually the debate between Noam Chomsky and Michel Foucault. I thought I’d do something or other with that dialogue, it wasn’t clear what, and I met with a composer friend, Joanna Bailie (who is the musical director of Yesterday Tomorrow), to see if she might write some music for the project, and at some point in our discussion she mentioned Alan Turing and the 1950 essay “Computing Machinery and Intelligence.” Once I read it the whole project took shape in my mind. Not to go too far astray from your question…Turing’s essay argues that the traditional way of thinking about developing AI was no good – that trying to create the property of thought in a machine would never work, mostly because we don’t really understand what “thinking” is – we humans don’t know very much about consciousness, how we do it, how it works, and so on, so how could we possibly create it outside of ourselves? He proposed rather that we work on trying to persuasively convince a human observer that thought is taking place in a machine – in other words, that we try to create the effect of thought rather than thought itself. In his formulation, thought is in the mind of the observer, not an inherent property of a thing/being itself. It’s obviously one of the giant ideas of the 20th century, and when I read his essay, I realized how provocative it was for theatre. It’s inherently theatrical, it’s about the audience, it’s about the impact of an illusion on a human viewer. So that became the basis for Hello Hi There – to explore ideas about human nature, language, consciousness, natural language programming, and the relationship of all those to politics, by stirring together Alan Turing, Noam Chomsky and Michel Foucault in a big pot.

As I got further in that work, I began to get excited by the theatrical potential of algorithms more broadly. I started to see algorithms almost like little dramaturgs and little performers all in one, ordering and sorting information and presenting their results. There’s a kind of old cliché about theatre, originally from Stanislavski, you hear it in theatre classes all the time: “theatre is action.” And it was this quality of algorithms to act autonomously (or semi-autonomously) that really got me thinking about a whole range of projects I could do that would explore algorithms as theatre artists. 

I have always been more interested in theatre machinery, the structure, the whole apparatus, than in acting or in playwriting. I liked very much that by making theatre with computers as my primary collaborators I could dispense with a whole lot of theatre traditions and so-called accepted truths. Since then I’ve done a big research on early algorithmic visual art, and I think what I’m doing with theatre is analogous to the work of that first generation of computer artists, who were really experimenting with how to work with computers as compositional partners. I’m trying to bring algorithms into the theatre on the ground floor level, so to speak, and there are some challenges that arise, really fascinating problems to try to solve.  

» Is it important to the concept of the piece that the work be different each time it’s performed? How have the performers responded to this challenge? 

Annie: Oh yes, definitely. For one, that gives the work it’s live aspect – the computer system is improvising, each time. It’s not functioning as a playback machine, but rather is doing some creative work in real time. The focus is on the algorithm’s performance as well as that of the singers.

But maybe more importantly this is connected to the notion of multiples, there is no canonical ‘fixed’ version of the music (or in the case of Hello Hi There of the dialogue, or in A Piece of Work of the adaptation of the Shakespeare text). The music any given audience hears is just one possible output. The code is the fixed element and each night’s expression of that code is contingent, one of many.

In Yesterday Tomorrow the singers have no idea what music will be coming at them in the moment, and I think it’s big big fun for them. It’s not only an interesting challenge for musicians as skilled as they are – but it also gives them this kind of game to play, there’s an urgency and spontaneity to the performance that’s important to the thematics of the piece. They are forced to stay in the moment and to let the computer-generated music pass through them – so they become in a way part of the interface, part of the construction that allows the computer to present its work.

» As the Yesterday song takes on aspects of the Tomorrow song, the first thing that’s noticeable are small rhythm changes. Do rhythm, melody, and syllables change independently of each other in the algorithm? Were there other dimensions of the music that change from the first song to the second? 

Annie: Yes, we alter everything separately – each aspect is changing according to independent equations. These kinds of decisions were a big part of the rehearsal process for the piece, setting some parameters for the overall shape of the music. The other external logic we imposed was the tempo – that was in a way an obvious thing to alter through the course of the piece, to hear the results of the algorithm as completely as possible. During the music’s most chaotic scrambled phase we do a shift to very very fast (300bpm) down to very very slow (20bpm) – so that we experience it in radically different ways. And then from a theatre perspective of course, it also allows a shift in perception, which makes some relationship to the notions of past, present, and future we’re playing with.

from “Hello Hi There,“ photo by w.silveri/steirischer herbst

» Could you tell us a bit about what type of algorithm was used, and how it was developed? Did you know the work was going to be about an hour when you started? I’m curious about when these parameters became clear and how they were refined as the software was developed.

Annie: I went through a couple of different versions of the code. To begin with, I wanted the primary system to be a genetic algorithm, so the computer would have to arrive at “Tomorrow” through a learning process. I was attracted to the evolutionary model for the match it made with the metaphoric layer, but it quickly became clear that that was not a great way to go. I was working with a different programmer at that time, and he wrote a very clever program, but it just never got anywhere near “Tomorrow.” Not even close. And I knew I wanted that moment of arrival – I didn’t want to set “Tomorrow” as a goal but then just see what we got at some arbitrary end point – I really wanted to have the complete path. So we ended up using a kind of migration algorithm that would shift the pitches and the durations of each note from “Tomorrow” to “Yesterday” in a series of steps. So the number of steps is decided by us – we started with 40 I think, our first tests, but we felt it was too long, we were in the scramble for too long to stay interesting. So we kept shortening it until it felt right, now we’re at 30 steps. Some of that also had to do with the physical limitations of the singers – I wasn’t interested in totally exhausting them, or in them killing their voices, and it’s not such an easy score to sing – so we kept it reasonable, both for their sakes and for the audience’s attention.

Most of our rehearsal work was spent finessing the algorithm – the equations that govern the rates of change, the tempo shifts, and of course setting up and debugging the interface, how the score will appear visually so it makes sense in terms of musical notation and the singers can read it. 

The core team in all this was Pierre Godard (programmer) and Joanna Bailie (composer) and me – we each have a different area of expertise, you could say, so there was a kind of productive push pull around the integrity of the algorithm, the integrity of the music, and the integrity of the event or experience as theatre.

Will let Pierre answer in more detail…

Pierre: So the migration in Yesterday Tomorrow is relying on iteratively mixing gaussian distributions centered around “paired” notes from Yesterday and Tomorrow. The pairing is randomized for each performance (if i remember correctly, Tomorrow had more notes and so it was necessary to drop some of them randomly to have a one-to-one association with Yesterday’s notes, and then eventually re-inject them later in the process). Once every note from Yesterday is associated with a note from Tomorrow (the “target” note), we decide for each note with a certain probability if its pitch should be changed or not. This probability is very low at the beginning of the migration and increases (according to a sigmoid “S-shaped” function) to reach 1 at the end of the migration. If we decided (or rather the pseudo-random number generator did) to change the pitch, we make the mixture decision: is the new pitch going to be drawn according to a gaussian distribution centered on Yesterday’s note’s pitch or Tomorrow’s? At the beginning of the migration, we’re more likely to be centered on Yesterday’s pitch and as we move forward, more likely to be centered on Tomorrow’s pitch. Then we draw a new pitch (which also involves choosing a standard deviation, that also evolves throughout the migration and is at its highest in the middle of the piece. Note here that Joanna proposed to use a chosen “musical” distance rather than just a pitch difference, so a perfect fifth is for example a smaller jump than a minor second). We repeat this for duration and syllables, which gives us a modified version of Yesterday, and we iterate the whole process from this current version of the song. I should add that when we have reached either the target pitch (or duration or syllable) of one of Tomorrow’s notes, the probability of changing it equals 1 minus the “sigmoid” probability i mentioned above. That, together with the evolving standard deviations we chose, ensures that the whole thing converges to Tomorrow.  

This program is rather ad-hoc, it does what it’s supposed to do and doesn’t have too much of a gravity center on its own conceptually. However, as Annie was saying, a lot of work went into finessing it and fine-tuning its parameters. Each step of it is very simple, but its iterative nature makes some complexity arise, and intricate effects start to manifest. You inherit anything that happens throughout the process. Faster change rates at some point in the migration can lead to slower ones later, or more noise lead to a more abrupt “resolution” into Tomorrow.

» What was the code written in?   

Pierre: The code producing the score is written in Python, but all the interface for the singers is built with Max, and a Max library called ”bach“ developed by composers Andrea Agostini and Daniele Ghisi.

» Annie, in your "On Algorithmic Theatre,” you talk about the algorithm as both performer and collaborator. What was it like adding human performers to the mix, mediating the algorithmic output? I’m curious if the mix of comfort and rigor on the set references this collaboration (the couches, those boot/sock things, etc).

Annie: The design of the piece has more to do with what I refer to as the theatre-side of things, by which I really mean the metaphoric aspect. I was thinking about my own experience of change over time – that days, months, years pass but there is a certain continuity, especially of the most banal aspects of living: sitting on a couch, brushing your teeth, making tea, that sort of thing. At one point I was thinking about each move on a sofa kind of standing in for a different moment, like if you would take a photo once a day for a year, you would have all these images of different positions on the same piece of furniture. The weather outside would go from winter to spring to summer to fall, wars might start or end, love comes and goes, and all that - but inside at home the person is just one day sitting with legs crossed and the next day has an arm over the back of the couch.

Once we put the whole thing together, I found it was a good opportunity to make some associations with the ubiquity of algorithms in our lives, the extent to which we are already 'taking direction’ from them, how much our daily lives are entwined with and shaped by these little pieces of code. The sofas, the laptop, the TV, the iphone – that staging became a way to bring out what was already inherent in the piece: three hopeful humans with their eyes (of necessity) glued to a screen, being kind of bossed around by this computational system. I’ve been putting it like this: you don’t choose what you get from the world, but you do choose what you do with it, sometimes only in limited ways. But still and nonetheless, those choices matter.

Photo by Maria Baranova

» Your algorithmic theater work and pieces such as “Democracy in America” take a theater-as-experiment approach that feels informed by contemporary art as much as theater. Could you talk about influences from outside theater on your work?

Yes, contemporary art, but equally contemporary dance. I started to get a bit of a dance education in the mid-2000s, at a place called Performing Arts Forum in France (it’s an amazing place, I won’t go into it but interested people can check out www.pa-f.net). In particular, two aspects to what people were doing there drew my attention. The first was the overall project to posit thinking as a physical action, and physical action as a form of thinking. When I began to explore what that notion could mean to me in my theatre practice, I imagined a form of theatre in which an idea, rather than a represented character, would take the place of the protagonist. In other words, the audience would be tracking the development and changes and so-called 'arc’ of an idea rather than that of an actor playing a role. The second aspect was a methodology; most of the choreographers I met at or via PAF were making dances through the development of a score, or a precise procedure. That wasn’t new to dance in the 2000s, of course, but it was new to me, coming from the New York theatre scene. And that way of thinking about process opened a big new field of experimentation.

The influence of visual art came a little later (except insofar as the dance works that influenced me were themselves influenced by conceptual art, minimalism and other postmodern forms of the 60s and 70s.) I’d started looking into the work of early computer artists, Manfred Mohr and Roman Verostko and others. I mentioned above that as I was in such an early stage of development with algorithmic theatre, I felt I could learn a lot from the corresponding early stage of computer art. I read some texts by Manfred Mohr from the late 60s that struck me as really helpful, some artist’s statements he’d written that laid out the basic principles he was working from. Those writings helped clarify some questions I’d had already, and alerted me to some fundamental differences in medium between visual art and theatre that provoked some good thinking. At times during the creation of A Piece of Work, it seemed like anytime I was stuck I could go back to one of Mohr’s texts and find he’d dealt with some analogous problem in his own work. A lot of the issues have to do with how to define the steps involved – so you can teach a computer how to do it. That means being able to make the process rational and concrete, which for all kinds of reasons is a different ballgame in theatre than in two-dimensional graphic art works. I have decided to pursue a back and forth between me and the algorithm, a mix of the rational and the irrational, the mathematical and the aesthetic. My big interest in this work, after all, is to understand something about how humans and the tools we create mutually transform each other, how we create the tools and the tools create us back.

[softclindgren]

Readings for undergraduate Rhetoric, Technology, and the Internet course

Below is a list of readings for the course that I will be teaching in the Spring 2016 semester: Rhetoric, Technology, and the Internet. In the past, I've tried to bridge the disconnect between rhetoric's focus on discourse and its limited studies of materiality, mediation, and action. And, how the focus on the former often leaves language use and production as activities discrete from technology and even as "technology". So, these reading are meant to jar our minds a bit about what indeed language and its use is/are and its relationship to technology, and to consider language as technology.

Burke (1950/1969). Traditional principiles of rhetoric. Chapter 2 in A rhetoric of motives. University of California Press, pp. 49-65.: Meant to succinctly review the tradition of rhetoric and re-purpose Burke's call to construct "extensions" (p. 64) of it.

Excerpt of Vygotsky's Thought and langauge Translated by A. Kozulin (2012), pp. 103-132. This excerpt focuses on Vygotsky'research of how children form concepts and make sense of the (material) world. I'm pairing it with Carolyn Miller's (2009) position paper "Materiality versus language" and Gregory Bateson's (1948/2000) metalogue "Why do things get in a muddle?" Both of these, I think, will compliment Vygotsky's work on semiosis. I hope we can open up discussions about the Burke reading from last week and sense-making this week.

Excerpt of Amy K. Roundtree's (2013) The rhetorical situation of simulations in Computer simulation, rhetoric, and the scientific imagination, pp. 9-18. Paired with excerpt of Chuck Petzold's (2000) chapter's from Code: "Best friends" and "Gates (not Bill). These readings challenge the bifurcation of meaning and meaning-making as something reducible to merely linguistic signs. Meaning becomes how people do/be within distributed systems and contexts. They will hopefully help us build on our own conceptualizations of rhetoric as related to technology, mediation, and sense-making.

Jennifer Edbauer Rice's (2008) position paper on regional rhetorics: "Regional rhetorics and the cosmopolitan dialectic" as paired with Armond Towns' (2015) "That camera won't save you" from Present Tense. Both help open up discussions about how culture, community, and contextual constraints influence how people make sense of and produce narratives about events. These 2 pieces, again, build on prior weeks of discussions related to how people make sense of and produce discourse and artifacts and technologies. In short, how is it that people come to different understandings and then identify with groups based on such understandings?

Excerpts from Perelman and Olbrechts-Tyteca's The new rhetoric, pp. 261-305, 362-368. Our focus will be on the "Structures of reality" arguments and "Model and anti-model" arguments. These sections focus on how people construct sense of a situation as a way to stimulate response(s), which will build on last weeks rhetorics of difference.

Susan Leigh Star's (1999) "Ethnography of infrastructure" as a way to start considering how we might go about researching how people have what we're calling "rhetorical experiences" with web-based technologies. Thinking of it as a synthesizing week and Star's piece is the agent to catalyze us into the group "rhetorical experiences" research projects.

We will then probably read some basic ethnographic methods works to help students understand what kinds of data they can collect to create preliminary studies about rhetorical experiences with web-based technology.

Updated/Finalized Reading List

See the syllabus at http://3577ws16.clindgrencv.com/.

Burke (1950/1969). Traditional principles of rhetoric. Chapter 2 in A rhetoric of motives. University of California Press, pp. 49-65.

Lipson, Carol. (2004). Ancient Egyptian rhetoric: It all comes down to maat. In C.S. Lipson & R.A. Binkley (Eds.), Rhetoric before and beyond the Greeks, (pp. 79-98). Albany, NY: State University of New York Press.

Excerpt of Vygotsky, L. (2012). Thought and language. A. Kozulin, (Trans.). pp. 103-132.

Bateson, G. (1948/2000). Metalogue: Why do things get in a muddle? Steps to an ecology of mind. publisher. pp. 3-13.

Miller, C. (2009). Materiality versus language. Proceedings from the USC Conference on Rhetorical Theory, Columbia, South Carolina. Retrieved 05 Jan. 2016 from http://artsandsciences.sc.edu/engl.archive/rhet_theory_conf/2009_papers/c_miller.pdf

Bitzer, L.F. (1968/1995). The rhetorical situation. In W. A. Covino (Ed.), Rhetoric: Concepts, Definitions, Boundaries. Boston: Allyn and Bacon.

Chapter from Roundtree, A.K. (2013). Computer simulation, rhetoric, and the scientific imagination: The rhetorical situation of simulations, pp. 9-18.

Excerpt from Strec, Goodwin, & LeBaron. (2013). In J. Streeck, C. Goodwin, & C. LeBaron (Eds.), Embodied interaction: Language and body in the material world (pp. 5-8). Cambridge, MA: Cambridge UP.

Chapters from Petzold, C. (2000). Code: Best friends (pp. 3-8) and Gates (not Bill) (pp. 102-105).

Edbauer Rice, J. (2008). Regional rhetorics and the composition dialectic. Proceedings from the USC Conference on Rhetorical Theory, Columbia, South Carolina. Retrieved 05 Jan. 2016 from http://artsandsciences.sc.edu/engl.archive/rhet_theory_conf/2008_papers/Rice.pdf

carrington, a. (2015). Implicating the state: Black lives, a matter of speculative rhetoric. Present Tense, 5(2). Retrieved 05 Jan. 2016 from http://www.presenttensejournal.org/volume-5/implicating-the-state-black-lives-a-matter-of-speculative-rhetoric/

blas, z. & m. cardenas. (2013). Imaginary computational systems: queer technologies and transreal aesthetics. AI & Society, 28, pp. 559-566.

Cooper, M.M. (Feb. 2011). Rhetorical agency as emergent and enacted. College Composition and Communication, 62(3), pp. 420-449.

Excerpt from Connerton, P. (1989). How societies remember. Cambridge, MA: Cambridge UP, pp. 25-36.

Star, S.L. (1999). The ethnography of infrastructure. American Behavioral Scientist, 43(3), pp. 377-391.

Ellis, C., Adams, T.E., & A.P. Bochner. (2011). Autoethnography: An overview. Forum: Qualitative Social Research, 12(1). Retrieved 14 Jan. 2016 from http://www.qualitative-research.net/index.php/fqs/article/view/1589/3095

Wolfinger, N. H. (2002). On writing fieldnotes: Collection strategies and background expectancies. Qualitative Research, 2(1), pp. 85-93.

Sanjek, R. (Apr. 2012). A vocabulary for fieldnotes. In R. Sanjek (Ed.), Fieldnotes: The makings of anthropology (pp. 92-121). Ithaca, NY: Cornell University Press.

Pace, S. (Apr. 2012). Writing the self into research: Using grounded theory analytic strategies in autoethnography. TEXT, 16(1). Retrieved 14 Jan. 2016 from http://www.textjournal.com.au/speciss/issue13/Pace.pdf

[hellocatfood]

oh look databending now is on wikipedia

[esoteric-codes]

The Less Humble Programmer

In his classic paper “The Humble Programmer” (1972), Edsgar W. Dijksta called for putting aside personal style and overt cleverness in the interest of creating clean, readable, functional code. As he put it:

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

This can be thought of as a sequel to his “A Case Against the GOTO Statement,” (1968) which helped standardize a structured programming style built around a sense of flow – this is the next step toward readable code. Personal expressiveness at the code level such as using arbitrary variable names or employing obscure hacks (whether just to show off, or in the service of efficiency) reduce readability. It’s not only a problem for other programmers who may have to understand the code later, but, as Dijsktra points out, even more so for the author of the code herself, who has to fully understand what’s happening as she writes it. When low-level, bit-shifting hacks really are appropriate (e.g. when algorithmic efficiency is mandatory), the current norm is to include comments to explain what is happening, which are simply compiled away. Even those proponents of more minimalist styles like Spartan code are doing so with clarity as an overwhelming objective.

However, clever hacks are still with us; it is exciting to discover twists of logic that make code do weird things. Take for instance the recent post on JSFuck, where one brilliant, demented programmer used a behavior of JavaScript generally considered useless – that it returns the word “Array” from Array.toString() – in order to recreate the alphabet, building from those letters – and thereby writing code without using any letters at all. The result is a brainfuck-like stream of punctuation which is still perfectly valid JavaScript runnable in any modern browser. If the feature is there, even the completely useless one, some programmer will find a perverse use for it, no matter how absurd it may be. [See also: the templating language of C++ is itself Turing-complete]

Practices like esolangs, obfuscated code, one-liners, and code golf are all Less Humble practices. They create spaces for play in code, where it’s okay to use weird hacks, write the unreadable, or stretch the boundaries of programming.

The approach of using secondary features of code (like Array.toString() above) is a common strategy in Obfuscated Code, a style of programming which is perhaps the most obvious counter to Dijkstra’s advice. To obfuscate is to make code opaque – to draw attention to it as a text, reducing the ability to see the algorithms behind it. 

The best-known competition for Obfuscated code is the IOCCC (the International Obfuscated C Code Contest). Many entries there opt for a form of code pattern poetry, laid out to resemble shapes or images, often in conversation with what the code performs, such as this work: 

Adrian Cables’s 2012 winning entry features a quick brown fox, pattern poetry style. This is an OCR program – a program designed to convert analog writing into digital text, itself built in a form which refers to the alphabet directly (the “quick brown fox…” sentence) and is itself an illustration of that sentence – referring to it both in analog and digital means, written in an unreadable style.

Others might appear as if they were written in other languages like Visual Basic or Java, yet still functioning as valid C. To do this, a Visual Basic command named one way to actually carry out much different instructions, remapped by preprocessor instructions. 

Interestingly, the IOCCC rewards attention to detail that are familiar as Dijsktrian goals: stability, including handling unexpected input, working across compilers. Many of the familiar values of mainstream coding are still in effect, just carried out in a completely different aesthetic. In a sense, this work challenges Dijkstra’s pronouncements while still internalizing its values. It is a place for code that must be successful according to the same criteria, yet written in a way that explicitly breaks from the sentiments of clarity and humbleness he gives us to help make the work successful in the first place. 

Nick Montfort’s “Obfuscated Code” (in the wonderful collection Software Studies) looks at the principles behind this work:

Obfuscated code demonstrates that there are other aesthetic principles at play besides those “classical” ones that have been most prominent in discussions of programming aesthetics by programmers and critics.

One of the aesthetic principles of Obfuscated Code that Montfort mentions is that of conciseness, which is further emphasized in two other Less Humble coding styles: One Liner programs (which Montfort offers some great examples of in his piece) and Code Golf, a set of challenges that reward the shortest program which completes a specific task. Code Golf challenges offer Oulipean-syle constraints (not using the letter “e” is perhaps too easy, but not using letters you’ve already used provides a substantial challenge). Code golf can involve obfuscated programming outright as a challenge, but more commonly techniques arising from obfuscated practice are used in order to solve code golf problems. [Stack Exchange has an active Code Golf forum]

Where code golf and obfuscated code willingly embrace esoteric methods of programming, we can also see in these alternate methods a breaking away from the safety of high-level languages, a call back to what programming was like in the days of machine code – particularly in esolangs themselves. 

Wendy Hui Kyong Chun has written about how giving up the direct interface with the machine was hard for early programmers. Chun quotes John Backus, developer of FORTRAN about the “black art” of early coding, saying they had a

“chauvinistic pride in their frontiersmanship and a corresponding conservatism, so many programmers of the 1950s began to regard themselves as members of a priesthood guarding skills and mysteries far too complex for ordinary mortals. Languages like FORTRAN opened up this world to people who were not trained in this black art.”

In a sense, alternative coding practices recreate this sense of code as an esoteric knowledge. Here not in a chauvansitic way, but with a sense of excitement in breaking new ground within deliberately obscure rules offered by an esolang or a set of code golf constraints. Each esolang creating a unique means of communicating with the computer that make sense only to esoprogrammers willing to bypass the niceties of mainstream computing. Esolangs may convolute code but do it in a way that gives esolangers access to low-level activity masked in the name of safety and ease provided by these high level languages. As crazy as brainfuck looks, it forces one to deal with memory cells directly; much of the delight of the language is in this engagement with the machine which is obscured by the safety of high level code and the “humble” approach of reducing complexity. The most extreme of which is probably Checkout, a language proposal that tries to give direct chip access to the programmer. 

This opaque code – whether in the form of obfuscated work or esolangs – is also an exploration of code and language design as mediums in themselves, as much as deliberately using tape hiss or jpeg compression in visual studies of those media. 

[softclindgren]

Writing and rhetorics of code or #wrcode: On field-building

This late morning I posted some tweets about Apple's ridiculous non-standard practices to serve up Apple touch icons or favicons. As I tweeted about the resource, I paused for a moment to think that this sort of material could be studied in some diverse ways by scholars in writing and rhetoric, who all carve up different dimensions of code/coding.

On Twitter, Kevin Brock started a #rhetcode hashtag, and I started a #writcode hashtag. So, why not combine the two as #wrcode, I thought. I tagged some folks in the tweet seen below. Brock wanted me to expand on my reasoning, so this post attempts to do just that. (Please note that I wrote this post in haste, as I was at home with my kids. I wrote it up while preparing dinner!)

@lndgrn @anetv @cbdilger @techairos @estee_beck @timlockridge @jamesjbrownjr go on...

— Kevin Brock (@brockoleur) October 14, 2015

Since 2009, over the course of my graduate school experience (MA to now PhD candidacy), I've been trying to come to terms with how I theoretically understand writing activity and rhetorical practices, generally. More specific to my own research goals, I have been crafting an epistemology in tandem with how to research programming as a form of writing. I have been pouring over different humanities approaches to understanding computer programming in ways that compliment and differ from traditional knowledge domains in the computing sciences and social sciences. Many of the people that I tagged in the tweet above are scholars crafting their own epistemologies in fields such as Literacy Studies (Vee), Rhetoric and Software Studies (Brown), Rhetorical Genre Studies (Brock), Rhetoric and surveillance (Beck, Hutchinson), the intersection between Composition Studies and coding (Dilger, Lockridge), and my epistemology with its own lineage.

Of course, these bins are not this tidy, but they represent my interpretion of these scholars' more particular epistemological aims to understand code, coding, or, as others frame it, as computational media. Writing and rhetoric more broadly conceived is the more common disciplinary ground that we all share. Some position themselves more in writing studies, others rhetoric. Each also combine their research aims in relation to some other discipline.

Accordingly, I thought in that small, but "pregnant pause," about a proposition. I thought: we, and of course other interested scholars who I couldn't fit into the tweet above, should find more spaces to publicly explicate how we differ, intersect, and synthesize. The hashtag, #wrcode, is but one small gesture toward larger spaces to do some field-building.

Overall, I think that such a collegiate aim will help all of us more explicitly recognize our shared disciplinary space, but also our differences. Because, if we do that task for ourselves, I think we make it easier for others to join into our growing field. And, we can make it easier for us to know how we come at and to particular projects related to programming. Perhaps, we could call such a field, "Writing and Rhetorics of Code," where we can all to work together—sometimes in very different ways.

Really, I just want to see these humanities approaches to code really take off over the next decade. This #wrcode hashtag, again, is just a small moment / thing that can help us on Twitter. Strength in (growing) numbers!

One final note. I don't mean to exclude others who have done and been doing this work for quite some time. If you're not represented here, it's more of a product of lack of time to add the breadth of work in the humanities and code/coding. I definitely know it exists and has been around since at least the 1970s (see Hugh Burns), and of course others outside of writing and rhetoric based disciplines as many of us have historicized.

Update: Regarding previous scholarship, Annette Vee put together a bibliography a few years ago. This seems like a good place to link to it, again: http://www.annettevee.com/blog/2012/06/07/proceduracy-annotated-bibliography/.

[softclindgren]

‘How do you  know what they are doing?’

Hutchins (1995) on human performance. How doing and saying, even mundane work activities, are quite complex:

A student was making a point about what people do at work, saying that in an auto factory people mostly make cars. Roy [D'Andrade, the professor] said something like: 'How do you know what they are doing? Maybe what they are making is social relationships and the cars are a side effect.' (p. 225)

[softclindgren]

Shoutout to designers and devs who know that communication is key to their process

The following links are to articles of designers and developers, who are writing about the ways communication is integral to their process. As a writing studies researcher and teacher, these articles bring little tears of joy to me eyes. Because, yes!!, written and spoken communication are essential practices.

Al Scott, "Using Cookbook Documentation to Pass on Knowledge."

Soundbite: "Documentation is hard. Like writing code, it is a delicate balancing act of packing information into a format that is both very dense and very readable."

Alla Kholmatova, "The Language of Modular Design."

Soundbite: "Naming things together is a useful habit for your team to develop, because in the process of trying to give something a name that makes sense, you work out its function and, most importantly, reach consensus."

Abby Covert, "How to Make Sense of Any Mess."

Key message: Work professionals need to pay closer attention to developing a shared language, or "controlled vocabularies."

Nicole Fenton, "Words as Material." h/t @caseyboyle

Soundbite: Provides a nicely defined problem to tackle and says, "We’re [designers] here to make meaningful changes in the world, but we can’t do that if we don’t understand each other. We can’t ignore people or work around them."

Again, it's so great to read about designers and developers discussing these issues, solutions, and strategies surrounding communication. I find myself nodding my head in agreement with much of what they're preaching. I see them starting to realize how even the seemingly simple act to name a thing is an interpretive act that conceptualizes design goals and functions of particular aspects of a tech being developed. I also see them knowing and seeking to know their audiences. And, overall, I see them convincing other design and dev professionals that their teams need to invest in communication time up front, as well as test such concepts and applications with the actual people who are going to be using the tech in particular goal-oriented ways.

Written communication is indeed language made material. Language use is a complex tool, inextricably bound to our bodies, contexts, and cultures of practical activity (cf. Haas, 1996, 1999; Haas & Witte, 2001; Witte, 1992). I think I like Edwin Hutchins' (1995) way putting this phenonema best: that humans are the "coordinating tissue" within the systems of activity that include particular people and tools being put to use in particular ways. It's no wonder then that designing and using technology is a bear to do and understand. It means we must admit that culture and tool use are intertwined, which then means tech-folks need to get real about the complexity of culture!

[softclindgren]

“It’s just a tool”: What does this actually tell us?

A quick thought on this soundbite that I hear quite often among people, developers, engineers, scientists, etc.: "It's just a tool."

I think I get what people are trying to say when they say this. They want to put the emphasis on humanity. And, that's a good, cool intention. But, I think this bifurcation backfires.

Let's assume that this is the way to go: the way to think about tools and humans, and how they inter-relate. What explantory power does it yield? What assumptions are driving it? Values? And, how does this logic serve a particular group's vested interests? Personally, I think it tells us, anyone, very litle other than a subjective undertanding about whatever tool is in question. Such a logic invites and reduces tools and people to utilitarian argumentative grooves.

Instead, I think a better way to understand tools is within an understanding that tools, their design and use over time, create domains of practice and knowledge. Such practices are inherently cultural, using sign systems and the human body in particular ways to develop a social an cognitive framework to deem actions as good, bad, appropriate, best, worst, etc., etc. There's a dynamic between historical prior interactions and a usable past that makes such human-tool relations become recurrent and context-specific all at once. To me, thi sounds far more interesting and indicative of the multiplicity of a tool.

Don't you think?

[softclindgren]

Thought-sketch: Material rhetoric of tech: Perceiving yet to be understood capabilities

Just a quick thought on why people tend to construct myths surrounding technologies and intelligence. In other words, why do people swoon over others with novel technology, or conflate technological use with knowledge and knowledge construction and production? Maybe I should contextualize this broader question into a more specific instance that I experience quite often: Why do people think children are inherently smarter because they can play games on iPads?

Part of what I study is the rhetorics of technology. This is not just what and how people talk about technology, but also the perception and construction of what people do with technology. The two facets, discourse and action, are intertwined. When I recently re-read some parts of Hutchins (1995) Cognition in the Wild, the following passage struck me as related to the aforementioned phenomena in question:

An important aspect of these interrelated social and computational structures is that both of them provide constraints on the behavior of the participants. One can embed a novice who has social skills but lacks the computational skills in such a network and get useful behavior out of that novice and the system. … one can be functioning well before one knows what one is doing, and one can discover what one is doing in the course of doing it. (p. 224)

Here, Hutchins is talking about how people accomplish goals through mediating instruments, i.e., tools. But, often, people work in contexts with multiple people and multiple tools, all of which create what he calls a functional system. Functional systems is a methodological framework with a rich past that goes back to A. Luria, but I won’t get into that here. What’s interesting about the passage above is how a functional system of people and tools can sometimes provide enough constraints, or representational markers, that clue people with enough social skills to be able to join in new-to-them computational tasks before they even know what they are doing. From this passage, I thought of the questions that I so often think about above and wonder how such the ensemble of novel technologies and simple motor capabilities made possible by the tech lead people to produce strange causal links about having and using a technology and intelligence.

I know this is a rather tenuous link, too, but this is why I love and hate rhetoric all at once: it’s a mind-bending cocktail of inferences and implications. People construct some strange logics about and with technology, and I think functional systems in tandem with some rhetorical ethnographic studies would proffer some new and interesting theories of the rhetorics of technology.

[dressprofesh]

The 7 Deadly Sins of Summer: The Body Positive Edition

By Katie [@katiemanthey]

*Note: this piece is written in reaction to this post from the Lansing State Journal: http://www.lansingstatejournal.com/story/life/shopping/georgea-kovanis/2015/06/24/7-deadly-sins-of-summer/29164781/

Summer is here, with sunshine, blue skies, and temporary lapses in judgment brought on by the lazy living in a capitalist society that creates and abnegates “acceptable” bodies.

Here are the seven sins of summer that you should be careful not to commit.

And no matter what, wear sunscreen.

1. Body shaming. Do you see a lady (or a guy!) with armpit hair? It’s becoming more popular right now, especially since Miley and Madonna are letting it grow. Do you have an opinion about it? Keep it to yourself. Shaming someone else’s body is never acceptable.

2. Body shaming. Do you like sandals? You should wear them! Are your feet dirty? Wear them anyway, if you want to! Don’t like sandals? Don’t wear them. See someone else wearing sandals with dirty feet? Don’t worry about it! Shaming someone else’s body is never acceptable.

3. Body shaming. We all have different comfort zones when it comes to how much skin we like to show in public. If you are the kind of person (guy or gal) and you feel the most comfortable covered up, then you should cover up! If you are the kind of person (guy or gal) who feels comfortable in booty shorts, midriff shirts, or even a sleeveless top ,then, by all means, wear it. The summer is hot, and it’s important to dress in a way that keeps you comfortable. Keep in mind your audience, purpose, and context and make a decision that is right for you. See someone else wearing too much or too little clothing? Don’t worry about it! Shaming someone else’s body is never acceptable.

4. Body shaming. I know, summer clothes are more relaxed than the clothes we wear in the winter. It’s a season of tank tops, strapless dresses, sleeveless shifts and halters. Be sure to wear a bra if that makes you feel the most comfortable and confident in what you’re wearing. If wearing a bra makes you uncomfortable, don’t wear one. If you see someone not wearing a bra (“flopping around”) don’t worry about it! Shaming someone else’s body is never acceptable.

5. Body shaming. Headed to some water this summer? Be sure to follow these guidelines:

See someone else in a swimsuit? Have an opinion about how they look? Don’t worry about it. Shaming someone else’s body is never acceptable.

6. Body shaming. The sun’s out and that means a lot of people like to get some summer color. If you are the kind of person who enjoys a little tan, be sure to wear sunscreen! If you are the kind of person who doesn’t want to be tan, then protect yourself with clothing and an umbrella while out in the sun. See someone who’s tan? See someone who’s not tan?  See someone with visible tan lines? Have an opinion about how they look? Don’t worry about it. Shaming someone else’s body is never acceptable.

7. Body shaming. The summer heat often leads to sweat. Sweat leads to sweat-stained clothing, and body odor. Do you see someone with sweat-stained clothes? Can you smell their body odor? Don’t worry about it! Shaming someone else’s body is never acceptable.

I think you get my point. If not, here’s an image that should cover the rest.

If you have questions, be sure to check out these body positive resources:

www.thebodyisnotanapology.com

www.dressprofesh.com

www.danceswithfat.com

www.fatbodypolitics.com