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.
» 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.
» 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.
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?
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.