From Building to Testing

Is it possible to build a viable MVP in 2,5 weeks without any prior programming experience? Yes, it is, the pilot group of Coding the Humanities proved this week.

Learning the Basics

The week started with a lecture on JavaScript fundamentals, where the students learned the ins and outs of variables, loops, functions and scope, as well as some tips and tricks on how to debug their code. Jan Hein did a few pair programming sessions with students to demonstrate the importance communication and collaboration in programming.

With these new skills they could jump the last hurdles of their projects. When we left on Tuesday evening, the hurdles still seemed quite big, yet on Wednesday morning everything suddenly clicked! With the house metaphor project finished, a short video was made to present their first product.

Testing your Basics

This week, Ashley Williams of Bocoup, an Open Web development group in Boston, joined the Coding the Humanities project for a few workshops about learning programming. Just as the students (and most of the teachers) in the pilot, Ashley comes from a humanities background. The students worked through several assignments with her on test-driven development and modelling Conway's Game of Life.

To Program is to Master Abstraction

The weekly open event on Thursday started with a presentation of the project the students had finished earlier in the week, which spontaneously evolved in a long presentation and discussion of their new project which aims to tie the Dutch open government data sets into their previous project exploring the house metaphor.

After the break, Ashley Williams talked about abstraction being one of the main hurdles to learning programming. She argued that lower-level languages can be easier to learn because they abstract away fewer things and are more explicit.

On Friday Lex Slaghuis and Arjan El Fassed of the Open State Foundation presented the many projects they run on hacking open government data.

Blurred Lines: Literary Perspectives on Programming Languages

I remember the day when I drew that first line on the screen of my computer using a command something like < line (x,y) >. I clicked "run" and indeed a line appeared. I had interacted with a machine that I'd formerly though of as both an enabled typewriter and a black box at the same time. I learned that my computer and I were capable of much more than text processing.

When I clicked run that day, something clicked within me too: I realised that programming and markup languages are just another type of language, only slightly different from those I'd been using my entire life. Treating programming languages as languages made them accessible to me. Yet, computer languages seemed much more able to eliminate ambiguity and appeared to be always performative.

The Story World of Programming Languages

Performatives, and its counterpart constatives, is a distinction made by John Austin in his 1962 work How to Do Things with Words. Constatives, Austin argues, are locutions (utterances) that say something about a state of affairs and can be either true or false. Performatives are locutions that accomplish something.

Literature (neglected by Austin) can be considered a prime example of performative language: it brings into being a new reality–characters, places, actions. Programming languages do the same. Javascript creates a space (a world) where var a = 5 changes the meaning of a from nothing or something else to 5 and Ruby allows for a space in which objects are made of text. These variables and objects (actors) play a role in the further development (actions) of the program (the story).

Of interest here specifically is a certain type of performatives: the explicit performative. The explicit performative is an act of speech (the overarching theory of performatives, constatives, locutions, and so on is called speech-act theory) that brings about a change in the state of reality. For example the sentence "I hereby pronounce you husband and wife." They need to be pronounced by a certain institution and under certain conditions. Yet, if the context is right, a set of words changes reality. Methods–a programming procedure that accesses an object in object oriented programming languages–can utter the programming equivalent of "I hereby pronounce you to …" and change the state or function of the object altogether.

A closer look reveals that not every locution in programming languages is a performative. Booleans–formulas that are return either a true or false–are a great example of a constative (a locution that says something about a state of affairs and can be either true or false). The story world of programming languages turns out to be as much a linguistic treasure as literature and human language are.

The Humanness of Speech

In literary criticism, ever since William Epson published his Seven Types of Ambiguity in 1930, ambiguity is considered a poetic device. If used properly, ambiguity adds to the complexity of the text as well as the experience of the reader. Poetry and literature turn ambiguity into a sign of quality rather than an flaw, as it was and is still often regarded in human communication.

In programming languages, as in human language, ambiguity appears as something that should be avoided–a typo or simply omitting a semi-colon at the end of a sentence quickly results in an error message. It seems that if you want a software program to run properly, everything to the tiniest detail has to be in control. However, second look at programming languages reveals that ambiguity is inherent in programming languages as in human language. While the so-called diamond problem causes programmers to seek ways to solve or avoid its ambiguity, game programmers are utterly comfortable with evoking spaces where ambiguity runs rampant.

Where computer programs become more and more complex and try to build increasingly complex forms of artificial intelligence, ambiguity seems to be more and more a prerequisite rather than an inconvenience. Human communication, despite how much we’d want it to, is never free of ambiguity. As literature has taught us, this is its beauty rather than fault. Subsequently, for a program to approach humanness as closely as possible, it has to embrace ambiguity and embrace its possibilities.

To a Shared Language

Allowing for ambiguity, however, entails opening up your artificial universe for unexpectedness, uncertainty and the potential of failure. Or as Nishant writes, this act diminishes the amount of control we can exert over these worlds:

A software program is really a rudimentary representation of reality with many axes of complexity reduced or entirely collapsed. The ability of programming languages to cut through ambiguity is actually a symptom of our own rudimentary understanding of the universe. We think that the ability of programming languages to eliminate ambiguity is a desirable feature (rather than a bug) because as humans we need to tell ourselves that we have some control of our environment.

Yet, the simple and deterministic programming culture of today is being replaced by more organic systems. Newer programming languages more closely resemble the way in which natural language works. The more natural the programs running our machines become, the less artificial they’ll feel. And the more room programming languages bear for ambiguity and complexity, the more their capability to represent our reality increases.

At first, human interaction had to be stripped down to its bare essentials in order for artificial intelligence and computer science to enact humanity in machines. Yet, today we’ve mastered the essentials and can add the complexities to it that make it human. We are ready to step away from software programs as the ideal and controlled versions of reality to machines that allow for complexity and the inevitability of uncertainty. The lines are blurred already. We should get ready for them to disappear.

– Charlotte van Oostrum (@cevoostrum) –With thanks to Nishant "@Rainypixels" Kothary, for filling in the gaps in my knowledge of programming languages and being an inspiring and insightful writing partner

Making Games from Data

"We want to take quantitative data and turn our papers into computer games that convey the theory," sounded the conclusion of the last presentation on last week's Coding the Humanities opening event.

But how can we turn theory into quantitative data? And what do you need to make a computer game? This week, we turned from the smaller group projects of week one to a large, collaborative project and started making a game.

Translating Data into Different Guises

During the first half of the week, Marijn, Jan Hein and Alexandro Mancusi from Weyeser gave introductions to API's, data sets, user stories, Json, Rest, Git and Firebase after which the students explored the tools themselves.

On Thursday, after a few days of technological immersion, Federico Bonelli of Trasformatorio reintroduced theory into data science and presented his work and ideas on interdisciplinary, truth and poetic terrorism. He showed how data can be translated and transformed into different guises.

Presenting Complex Issues

On Thursday evening, during the weekly open event, the students presented their collective work. They created a visualisation using mock data via Firebase, which they'd collected using a Facebook authentication system, and used words such as "two way data binding" without flinching. That's how far they've come already!

After the presentation, there was extensive room for feedback. We talked about how you present an issue in a clear manner, without hiding what complex questions this issue brings to the fore when you explore it.

Pitching your Ideas

Friday started with an impromptu lecture in project management by Nigel Hamlin. We worked on practical project management skills and worked on preparing a five minute pitch for the project. Next week, we'll film the pitch and make it available on the website.

We ended the week with a pair programming session after which the students were invited to do some live coding. And this amazing week ended even better with the amazing Dutch victory at their first World Cup game!

Starting Full Blast

After a short first meeting of the Coding the Humanities crew on Monday evening in the home-from-home in the pilot space, the actual programme started full blast on Tuesday morning.

As a short warm up, the students divided into small groups to briefly discuss their favourite websites. One would talk about their site, while the others would note down keywords, an image associated with the story and a slogan. After this, the students translated these stories into a HTML format and added CSS styling. At the end of the day, they presented their results.

The First Projects

On Wednesday morning, the group began the day with a "stand up"; in three groups they discussed how they had experienced the first day, was it tough, did they learn much, what issues did they run in to? The assignment for the morning consisted of working on developing webpages, in mock-up, related to three humanities’ themes or topics: "Power in the museum", "Identity and the selfie" en "Rhythms as a tool”.

Working collaboratively, they developed posters, which were presented to the larger group. After the break, each group actually developed the ideas on their posters by creating a page, after which – using github, the pages were shared, so that each could work on the page of another group. The day ended with a lecture about webcomponents.

What is Data in the Humanities?

After the stand up on Thursday morning, guest speaker Jan Willem Tulp of Tulp Interactive gave a lecture about data visualisation, after which the students worked on the question on what data is in the different humanities; what would you consider to be data, how would you problematize data and how would you be able to translate this into a webcomponent?

Using an actual project, paper or idea as a starting point, ideas were sketched on posters. The ideas of the students were very diverse; finding a common ground to discuss "data", and translating this into a visualization resulted in three designs.

The First Presentations

The day ended with an open event, where visitors and students could listen to short presentations by the Coding the Humanities team, the poster presentations of the students and share a drink and pizza.

When All We Have Is A Hammer

Coding the Humanities is not about technology or even programming. It is all about tools. Software is a blind spot for the humanities. While our discipline is deeply invested in self-reflection, we hardly ever think about the digital tools that we use to produce and disseminate these deep thoughts. As a result, we fail to see the obvious. The applications that facilitate our teaching and research, were not written for us, let alone developed by us. In fact, they are unfit for our needs.

In our research, we use a wordprocessor for almost everything. This factotum is part of a larger suite of proprietary enterprise applications, which is appropriately named after its intended use context. In an office setting this swiss army knife may be highly effective, but for research purposes it is rather blunt. Our pimped up typewriter does not offer any form of semantic mark up, has no citation management, and discourages collaboration.

In teaching, the situation is possibly even more dire. While the omnipresent word processor is a mismatch with our research practice, most online teaching platfforms go to the other extreme: they are indistinguishable from it. Or at least its appearance. Their user interfaces exactly mimics the classroom setting. Its conceptual metaphors are sessions, discussions, assignments, etc. This also means, however, that they make little to no effort to actually enhance our practice. Digital tools have the potential to radically change the way scholars teach and students learn. Unfortunately, this promise remains unfulfilled.

Even worse than the inadequacy of the individual research and teaching tools we use, may be the fact that they keep research and teaching completely separated. Of course, it is possible to embed text documents, hyperlinks and presentations in our teaching platforms, but that is about as far as the integration goes. We complain about the ever-increasing disconnect between our teaching and research, but do not realise that our current tools do nothing to help us bridge that gap.

No matter how bad our workflow is, we do not talk about tools. Humanities' scholar have more important things to discuss. We are interested in content, not in the structures that create it. We thereby selectively ignore most twentieth century theory which should have taught us to focus on the structures that produce knowledge rather than on their results.

How different is the situation in software development. Programmers shape their work environment until it fits their individual needs. However, this shaping and tweaking does not happen in isolation. It is done in a constant dialogue with the community. Developers fight entire wars over text editors and IDE's (Integrated Development Environments). If they do not like a certain framework or library, they write their own, add missing features, or fork the project. And this process of discussion and deliberation is not limited to the virtual environment. Standing desks, shoes, and dietary regimes are very much part of it.

Deliberate use of tools marks the difference between craftmanship and dumb labor. By solving all problems with their hammers, humanities' scholars reduce all problems to nails. Appropriate tools not only increase efficiency, they also enhance the ability to differentiate between different problems, and enable solutions to problems that have not even been discovered. Practice, not content, drives a field forwards. It is this very insight that motivates Coding the Humanities.

-- Jan Hein Hoogstad (@yeehaa)

Coding the Humanities is the title of a pioneering course which will familiarize humanities students with basic programming skills over the period of a month (starting June 2). This highly intensive, yet enjoyable experimental crash course not only aims at providing students a hands-on experience of coding and exploring an online workplace, but also aspires to introduce a new, practical-oriented model of research through programming, where researchers are free to develop and apply their own tools. The course allows students to investigate digital data from the perspective of the humanities.

Contrary to the bias against technology that is still dominant in academic circles, and to the conviction that certain disciplines are –or should– be excluded from the digital world, Coding the Humanities implements new unlimited practices of digital literacy, while challenging situated knowledge. By the end of the course, students will have reached an intermediate level of the latest standards in HTML, CSS and JavaScript, be able to develop browser-based widgets and be able to develop tools for humanities’ research. This enables students to translate complex theoretical problems into smaller, practical projects. As such, the pilot is part of a larger move to create an eHumanities lab at the UvA.

The course is open to bachelor, master and PhD students of different fields and academic backgrounds. No prior experience in coding is needed. The lessons and exercises will be in English. The students will be called to work on diverse exercises, such as developing interfaces, interactive pieces, data visualization et al, and the ones who will successfully complete the course will be granted 6 ECTS.

It is required from participants to work together in small peer-groups in the space of the lab, which will be open from 08:30 to 20:30 (working days) with the assistance of supervisors. During the four week course, a number of (inter)national speakers, from both public institutes as well as private companies, will give lectures and work together with the students. In the final week, students will present their work during an organized event. The number of participants will be strictly limited to 20 people. Interested students can register online by May 27. The selection process will be finalized by the end of May.