Blog Post

Is There a Linguistic Art?

I've recently begun the probably ill-advised project of creating a programming language. I'll give some details later, but first i want to pose the question: why, as a "humanist" (or whatever we are), am I doing this? Though it serves more of an enouraging than inspiring role, there's been a lot of buzz in humanist circles lately about creating programming languages. Of particular note is Areille Shlesinger's wonderful post on a feminist programming language here on HASTAC (, the ensuing controversy about it on the Misogynoweb, as well as a few more genuinely interested but confused computer scientists and engineers, and what were two follow ups to all that during the critical code studies working group at the beginning of the year. There we looked at codework (a sort of poetic code/codic poetry) by Mez Breeze ( and Micha Cárdenas (, and "قلب," an Arabic coding language written by Ramsey Nasser "highlighting cultural biases of computer science and challenging the assumptions we make about programming" ( This post is I guess a sort of prequel to all that, backing away for the moment from any particular goals such as anti-patriarchy and anti-racism, just to consider for a second this particular area of intervention: what are the possibilities in creating a codic language from the perspective of the humanities?

What has come up in almost every instantiation of this question is that it's pretty clear how to change individual lexemes for the better: the englishes of "if"/"and"/"else"/etc. can be internationalized; "true"/"false" could become a triple "true"/"false"/"indeterminate" (and it's been noted that this is already the semantics of SQL). What's less clear is how to change the fundamental assumptions of these languages themselves without (like codework) moving away from executability.

Thinking about this recently, I realized my questions about the potentialities of creating a codic language are actually *general* questions, which are brought out by but not created by the particularities of codic languages. Most of the extant language arts are exercises in arranging already-existing language according to the already-existing rules of grammar. I realize this may be controversial, so let me go over some examples. In "The Tempest," Shakespeare writes one of his more formally interesting poems, "Full fathom five thy father lies:/of his bones are coral made;..." In this we have many things which exert pressure on the grammatical structures in which they are contained: "of his bones are coral" poetically reverses the normal English word order; "full fathom five" draws attention to the sound of the word rather than its function as a sign. In M. NourbeSe Philip's *Zong!* for another example, erasure interrupts the grammatical sequence and applies pressure to the artificial coherence and visibility which any narrative would bring to the Zong massacre. And of course then there are the more aleatoric ("random") literary techniques, such as cut-up poetry or the surrealist "automatic writing." But all of these things, I think, in so far as they work against a language or even grammar itself, do so from within a language. The reversal of normal English word order is only possible because the rules of grammar provide a way in which unusual constructions should be understood; the sonic features of language are not foreign to language; the erasure of language is only visible as such due to the recognition of gaps which a linguistic understanding provides; and finally, however aleatoric a writing technique, the definite outcome is not understood aleatorically. In short, it's not that the extant language arts do not challenge or change grammar, but in so far as they challenge it, they challenge it by *using* it.

Of course this is completely different than the task of actually creating a language. Most artificial languages thus far, such as Esperanto or Interlingua, have been very pragmatic, although they clearly posess a certain elegance. The big exception here is Tolkien's languages. But it's interesting to note that his languages are inseperable from a fictional world, and a fictional history.

I think the issue here is that we have not clearly thought about the relations between the whole language and the linguistic fragments that constitute its definite use. Although (as Hegel says) "truth is the whole," changes to this whole do not, even for Hegel, take place as a deliberate posit of an entire system of relations to substitute for the existing system of relations. Instead, they take place because a certain relation within the system becomes a conflicting relation, which then becomes a contradiction. The contradiction implies the negation of the system, and implies the new system in which the contradiction is no longer a contradiction. This is what Lukács calls the "logic of content." The formal relations between ideas are inseparable from the delimitations of those ideas themselves, and consequently the alteration of the system is inseparable from the alteration of its individual elements. This is in a sense the principle behind Tolkien's proposition about language creation: that the creation of a language needs the creation of a linguistic history; that the history of people talking, the stories they say, and the histories which inflect the movement of speaking peoples, *are* the language.

So, to return to the question with which I began, what does it mean to create a programming language that challenges existing programming languages? Anyone who has written a sufficiently large program has experienced programming itself as language creation: the semantics of the subsystems themselves create the context of expressibility for shifts in that system, to one's delight or frustration. But in a certain sense programming is *not* language creation, as there is always some underlying syntax or semantics which you can't get around without returning to the task of actually writing a parser/interpreter/compiler. It is the absoluteness of this distinction in code between language and language content, unusual in our human experience, that creates the weirdness of trying to create a programming language as a humanistic intervention. On the one hand, one can create a language, but then one is somewhat unmoored from the literary body of code that constitutes the history of coding---that is, it's very impractical without a definite purpose that the language clearly accomplishes better than existing languages. On the other hand, one can create a sort of poetry of expression within code, in which the grammar is used in an unusual way, but there is a certain barrier here not present in natural language, in which the new expression can't inflect the language in which it was expressed, as there is always a compiler or a core language somewhere that is only rarely changed as a result of changes in content (I can't really think of an example; perhaps some principles of C compilers have been chosen to preserve Duff's device?).

The exceptions here are, I think, extremely interesting. Objective C, for example, is a strict superset of C, pushing C in a new direction, but still making sense to the community of C coders, as well as preserving a relationship with the body of code written in C. C itself was created at least in part to easily port B code. So here is one option: don't create a language as a whole, but as a critique or elaboration of an existing language. In many ways, this is what C, Objective C, and C++ are.

This is currently how I'm going about the language I'm creating: take C, then adjust one small thing: functions don't decompose to function pointers, and static variables within functions are externally accesible. In this way you can do sizeof(function), memcpy(&function, somewhere), easily create partially applied functions and a lot more interesting stuff that's usually relegated to the functional programming world. The structure, style, and even the thinking of programming can change through the change in the semantics of a particular object. But this is a more experimental approach and less like a deliberate approach, and its certainly not clear in this particular case that any sort of fundamental assumptions would be changed.

But another thing that I'm thinking about is, if compilers rigorously separate language and language content, should we be talking about language creation or compiler creation? Are there other techniques for compiler construction that would allow us to mitigate this rigorous separation? Or perhaps this separation is fundamental to computing in general?


No comments