Some Favorite Quotes from DH readings this week
Louis Milic "What's Next" 1966
"As long as the scholar is dependent on the programmer, he will be held to projects which do not begin to take account of the real complexity and the potential beauty of the instrument"
Ben Schmidt "Two Volumes: the lessons of Time on the Cross" December 2019
"In literary history and art history, there are huge arrays of digitized data and an array of fairly amateurish physicists and computer scientists who desparately need advice."
"So what I really think is that the division of books problem–the division of methodology and narrative–is one that is precisely adressable through these same kinds of challenges, because historians as much as anyone outside of digital journalists have been thinking about audience, narrative, and publics."
on the crisis of reproducibility in science "The literary and library scholars in DH (overmuch, to my mind) see one of their challenges as fully fixing those problems in digital humanities before they emerge through a tangle of IPython notebooks, online linked open data, and Docker configuration files."
"This kind of attention to audience, to re-ordering, and to narrative engagement evolved in part because of the weight of Time on the Cross. This–not warmed over introductory econometrics–is the real contribution to intellectual life that digital humanities stands to make. And its one that historians, with their multiple sources and strong subfield of public history, are better positioned to execute than any other field in Digital Humanities."
0 notes
Week 3 Intro to DH
Today's class went even better than I expected. The students seemed very into the topic and had really thoughtful questions.
This class was designed around the history of humanities computing and how it became DH, but we also read Tara McPherson's history of UNIX and covert racial logics in the 1970s.
I think the broader lens paired nicely with last week where we both learned about the command line and talked about studying code within a larger cultural context.
I also had them read the first article from Computers and the Humanities by Louis Milic, which made a nice primary source and was also a surprising read. In 1966, he was essentially making the case for DH, which raises some interesting questions about why we're still not there today.
We also experimented with Google Ngram, which would have been nice to read some of the work on the issues with its collections, but overall we got started talking about missing and skewed data, as well as what sorts of research questions are tractable with data.
I did assign another reading but a) it was the wrong one (should've assigned Susan Hockey's History of Humanities Computing and b) we're gonna talk about it more next week anyways.
Hoping this good vibe sticks for Thursday where I'm trying a flipped classroom model to teach an intro to Python 😅
1 note
·
View note
Second day of Intro to DH
So had my second meeting of intro to dh and far less successful this time around. Or at least there was a lot more awkward silences... sigh.
I was partially expecting it, since we're still in the shopping period, which means I lost one student and gained two more. And it means only half the students had read the article.
Mostly though I think I should've just tried to lecture more about the history of computing instead of have students try and describe code.
I also haven't found a good way to teach what is code to a mixed ground of students (half coders, half never touched code). I think maybe next time have an in class exercise where we diagram what makes code (people, binary, hardware etc...) vs how code impacts society.
They loved the command line maze exercise a lot, and seemed also fairly into discussing digital technology in their lifetime and what constitutes change/historic.
Overall, I think I need to bring in more STS when I teach code so it's less simply technical and more social construct. Also we did installation and setup, which is always my least favorite thing to deal with in class... there's always one windows computer that just refuses to work.
Next class will be history of DH so hopefully we can dig in a bit more...
0 notes
First day of Intro to DH
So just finished my first meeting of my new course at Princeton on Introduction to Digital Humanities.
Overall, I think it went well. I'm never very good at doing ice breakers, but tried to have them first think through what sorts of questions we wanted to answer for introductions.
What sorts of questions do you have about the course? About digital humanities? About each other? About me?
What is your name?
What are your academic interests?
Where are you from?
What is your experience in digital humanities?
What is your previous experience in humanities or digital (whatever that means)?
What year? Major?
What's your favorite app on your phone?
These questions were the final results. The experience in DH was a good one, whereas favorite app was maybe too personal. Should have added goals for the class as well in hindsight.
Next time I'm definitely going to do some more research on good ice breakers.
I also tried to do an annotate the syllabus exercise that I pinched from Anelise Shrout. I think the exercise is a great idea but I definitely flubbed the execution by falling back on narrating the syllabus when the students were silent. Again more scaffolding of in-class exercises is required.
Overall, the students seemed very excited for the direction of the course which is essentially an introduction to humanities data-driven research. Also they unanimously agreed on Python as our coding language of choice which was a huge relief (I swear I will eventually dig into R and tidyverse... just maybe a later day).
The final exercise went far better than expected. I had them read and refresh definitions of DH from whatisdigitalhumanities.com that Jason Heppler built. By the end students were starting to question how we define DH versus other fields, which is exactly where I hoped we would end.
Next meeting I'm hoping to give them a broader intro to the history of computing and then discuss what we mean by digital. Hopefully it goes well since students are still in the shopping period for classes (a weird Princeton quick where students get two weeks to try out courses).
0 notes
"So, while a conventional Lisp like Clojure might use the + symbol to represent addition, and write (+ 4 5) to add 4 and 5, قلب uses the جمع, Arabic for 'sum’ and writes the same addition as (جمع ٤ ٥)."
" A big part of قلب was exploring and intersecting the histories and traditions of Arabic and Computer Science culture, and building a Lisp was most appropriate for that."
"My experience has been that for many, the abstract formalisms of computer science are more intuitive than the random quirks of JavaScript. A turing machine is something you can draw and talk about."
"Code is a driving element of culture and politics, which means that code that is difficult to reason about or inaccessible makes for a culture and politics that are difficult to reason about and inaccessible. The conversation about programming languages has never been more human than it is now, and I believe this kind of work will only become more so as software spreads"
WOW... such a huge fan of Ramsey Nasser and his work 👏🏾💯
Interview with Ramsey Nasser
Ramsey Nasser is a software engineer, educator, and artist. He created the Zajal and قلب (‘alb) programming languages, the second while serving as an Eyebeam fellow in 2012. He has a BS in Computer Science from the American University of Beirut and an MFA from Parsons The New School for Design
» You have both a computer science degree and an MFA, which is still pretty unusual. When you were working on your BS, did you already have an interest in new media art, was it something that you thought much about at that point?
Not really. I knew that I wanted to 'do interesting things’ with code, something along the lines of graphics, something that challenged people, something that could make a difference, but that was about it. I knew than an MS in computer science wasn’t what I wanted. I hadn’t heard of New Media Art or any of this world until graduate school.
» Zajal is a pretty complex, full-featured language. Did you experiment much with language design before Zajal?
No, and to be honest, Zajal itself is a gentle introduction because it leverages Ruby so much. The compiler class was canceled when I was a student because no one wanted to take it. Zajal does very little parsing, as its mostly Just Ruby, but does a considerable amount of work internally to maintain the openFrameworks application state and all the appropriate bridges. It is really a giant Ruby DSL, the way Processing is a giant Java DSL. Being able to work in a language I already knew made it easier for me to hit the ground running.
» What was the original concept for Zajal, and did it grow into something substantially different? You mention Processing as the primary inspiration for Zajal – what was it that made you want to create a new language, as opposed to extending Processing in some way?
The primary motivation came from teaching Processing at the Parsons MFADT Bootcamp program. It is such an incredible platform, but it is held back by the fact that it forces people to code in Java, a dead-end language with zero interesting syntax or semantics. It makes sense given when Processing was written, but times have (thankfully) changed. The idea was to take the ground breaking ideas of Processing – trivial installation, graphics/input loop built in – but give people a language that was both more powerful and simpler to use. Extending Processing would have kept me tied to the Java ecosystem, which I find problematic in a lot of ways.
Zajal - Sketching from Ramsey Nasser on Vimeo.
» Where did the name and icon come from?
Zajal is the name of a form of traditional improvisational poetry from Lebanon. I grew up listening to my father’s Zajal CDs so the name is a nod to my heritage and upbringing. Also, a goal of the language is that it should empower people to improvise code fluidly like Zajal poets do to their verse.
The logo is an 'evil eye’ or nazar, which is traditionally hung over places to ward off evil spirits. By making it the logo of the language, displayed in title bars and file icons, I hope to ward off evil spirits – or bugs – from peoples’ code.
I do want to add some notes on the Zajal project if that’s OK: I am very proud of Zajal as it is, but I still think it falls far from its goals. Ruby is a great language, but it has bizarre unintuitive syntax in some places and areas that are completely unoptimizable (e.g. no native floats). Given the experience I have had with the language at Eyebeam, with students, and with artists, and the additional PLT knowledge I am revisiting the project this summer.
The goals are the same, with the addition that Zajal should be a platform for language experimentation as well as a language in its own right. The constraint I place on the project is that at its heart it should be made of existing technologies, so that users can take advantage of existing tools and documentation. Most of my language experiments have been in JavaScript, which is appropriate as V8 is one of the fastest dynamic language VMs available today, so this will most probably be Zajal’s new beating heart. There is a host if new asynchronous time semantics that I am excited to try out, and I am less concerned with maintaining 1:1 mapping to Processing or openFrameworks.
» One of my favorite features of Zajal is how changes in source code are reflected in currently running programs. What led to this being included?
In Zajal I was trying to minimize the time between having an idea and seeing it come to life. The language tries to achieve this in a variety of ways, but the live refreshing is the primary one. I wanted an experience that was different from the lengthy write-compile-observe-repeat loop, and something different from a REPL.
Being editor-agnostic was also an important goal, so watching a file for changes and updating when it changed was the most straightforward way to build it.
» With قلب ('alb), you created a programming language based in Arabic, the difficulties of which you described in this Artist Notebook piece for Animal New York. It’s interesting that you ended up building it in Lisp, which seems endlessly extensible through dialects of the language (I remember learning Logo in elementary school). What is the balance between working with Lisp vs. your experiments with Javascript in terms of the work itself and how easy it is for others to get use your project? Did you consider creating a javascript version of قلب?
قلب is built on JavaScript, it just uses s-expressions like a Lisp does.
I chose Lisp syntax for a few reasons. Lisps tend to be easy to write, and I knew I would be spending most of my time wrestling with Unicode issues, so I wanted to make the actual language implementation as simple as possible. Using a Lisp allowed me to base my interpreter on Peter Norvig’s lis.py.
I knew that calligraphy would be a part of the project early on, and my earlier experiments showed that punctuation does not translate well into calligraphy. This is not a problem when working with poetry, but becomes difficult when trying to render a programming language as a calligraphic piece when punctuation carries so much semantic meaning. Being a Lisp, قلب has no operators or special meaningful symbols outside of the parentheses, which can be dropped in a calligraphic piece. قلب goes further by requiring all identifiers to be composed of Arabic letters, numbers, and hyphens. So, while a conventional Lisp like Clojure might use the + symbol to represent addition, and write (+ 4 5) to add 4 and 5, قلب uses the جمع, Arabic for 'sum’ and writes the same addition as (جمع ٤ ٥).
Lisp is also one of the oldest families of languages in computer science. It originated in 1958 and its history is steeped in lore and tradition. For example, many Lisps use the function names 'car’ and 'cdr’ to access the first element and remainder of a list, respectively.
These names come from the names of the registers used on one of the original machines Lisp was built on in the 50s. There is no reason to continue to use these meaningless names (and, indeed, some Lisps like Clojure do not), but the tradition remains. A big part of قلب was exploring and intersecting the histories and traditions of Arabic and Computer Science culture, and building a Lisp was most appropriate for that.
» Exhibiting an experiential work like a programming language is a challenge, especially if you want both programmers and non-programmers to have some understanding of the work – could you talk a bit about how you approached this in showing قلب at Eyebeam and what the response was?
This is a challenge I first started dealing with while showing Zajal at Parsons for my thesis show, and one I don’t believe I totally have figured out. It is important to communicate that the art work is the language itself, not necessarily anything made in that language. To that end, I always make code visible to and hackable by the audience. When showing Zajal, I had a dozen example sketches on rotation projected on a wall, with a computer setup that displayed their code and invited you to hack on it. Some people came away believing my thesis had been a dozen graphics sketches, totally missing the code that was on display, which is the opposite of what I intended.
For قلب, I made the sketches simpler and did without the projector, emphasizing the code. What you see is a computer terminal with قلب code on one side and a running sketch on the other. An Arabic keyboard is made available to write code in. This presentation was harder to understand incorrectly, although not necessarily as transparent as I would like.
» You mentioned wanting to “'do interesting things’ with code.” In a sense, esolangs are a way of doing interesting things with languages. Were you looking much at esolangs when you began on the قلب project?
I have always been fascinated by esolangs. They are the such an amazing intersection of technical and formal rigor on one hand and nerdy inside humor on the other. The fact that they are not just ideas, but *actual working languages* is incredible. Its something that could only exist in a field as malleable and accessible as code. NASA engineers cannot build a space station as a joke.
Esolangs made it clear to me that languages could be a medium themselves, but what makes قلب unique is that it uses this medium to communicate a specific cultural and political message about code itself.
» In terms of the ITP class that you’re teaching, how are people taking to language design? For people who don’t necessarily have a comp sci background, is the learning curve steep to get started?
My experience has been that for many, the abstract formalisms of computer science are more intuitive than the random quirks of JavaScript. A turing machine is something you can draw and talk about.
The ideas are fairly simple when broken down. Even PEG grammar syntax has proven to be palatable . Knowledge of the implementation language (JavaScript in our case) has been the biggest stumbling block.
Students have been very enthusiastic. Code education in schools like Parsons and ITP tends to optimize towards results and hacking together code to make something work in a short amount of time. This is an incredibly important skill, but it leaves some students wanting to understand more fundamentally how all of these things work. My class attracts and serves those students.
» Any final thoughts on how work that engages code directly might change as coding becomes more of a common skill?
We might be entering a period where we can much more meaningfully reflect on society’s nature with software. For much of its existence, code has run in on servers or mainframes, or even on personal computers disconnected from the world. It’s a profound change when code runs constantly in our pockets, is making suggestions about how to move through space, who to pursue romantically, and what news events are worth your attention.
Code is a driving element of culture and politics, which means that code that is difficult to reason about or inaccessible makes for a culture and politics that are difficult to reason about and inaccessible. The conversation about programming languages has never been more human than it is now, and I believe this kind of work will only become more so as software spreads.
21 notes
·
View notes