Poetry as Code as Interactive Fiction (Jason Boyd)

Comments

• martinbartelmus

  February 25

  I am interested in the model of layers that, in my opinion, is evident here: Although the layers are connected to each other, even intertwined with each other, they serve, in the sense of Deleuze/Guattari, as archaeological strata: Code (Level 1), Text (Level 2), Function (Level 3). Not every text can be clearly read as poetry, just as almost no poetic text functions purely as code. Nevertheless, there are translation techniques in a certain way. The third level is the level of function or meaning. If this refers back to the paradigm of "poetry" (Level 2), then we can interpret the written as a poem. If the function refers to the written as code (Level 1), then we can play a game (interactive fiction). In my view, these functions are based on a readability linked to the paradigm of interpretability. In both cases, the game as well as the poem must not only be read but also interpreted. This is not to be understood so much academically. Interpretation here means playing in the case of interactive fiction and "enjoying" in the case of the poem.

  But how is "enjoyment" constituted? In my opinion, one can only arrive at enjoying this poem when one connects Level 2 to Level 1. That is, only when the poem is understood as code, and as you clearly demonstrate in your essay (paragraphs 9-16), does the power of poetic construction reveal itself ex negativo. Conversely, it does not seem to work as well, does it? Understanding code as a poem does not provide greater enjoyment in the sense of interactive fiction? But maybe I am not sufficiently immersed in the topic of interactive fiction here.

  I am inspired by what you have written in paragraph 18: the content of the sonnet refers to the inner burden. However, this inner burden, in my opinion, is closely related to playability and the question of whether, in the case of interactive fiction, we are really dealing with interactivity or if the "interactive" is more like a simulation of a sovereign reader? Consequently, neither an informed reader of poems nor of code will be able to answer the question of the subject's sovereignty better or worse. Rather, both reading functions point to a loss of sovereignty in the process of interpretation and understanding, a "burden" that must be borne.
• ranjodh

  February 25

  Just wondering how much of this happens with LLMs anyway, not only as the loop between natural and computational languages closes but also as generating legible, context-based explanations of code becomes easier for more people.
• anthony_hay

  February 25

  Hi @JasonBoyd. I'll try to answer your questions, as I understand them, from my perspective as a programmer.

  It seems likely that trying to understand a body of code where the same concept sometimes has one name and sometimes another will be harder and take longer than if each concept has only one name. If I'm reading code that mostly calls an erase_cell function, the first time I see a call to a delete_cell function I'm going to have to shelve the context I'm in while I go look up delete_cell. And I'd be puzzled if I found that it appeared to do exactly the same as erase_cell. I'd be asking myself what I'm missing.

  I'm with Einstein when he said

  It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

  Your second question reminds me somewhat of the tensions between graphical user interfaces, which may be easy to learn but less efficient for experts to use, and command line interfaces that may be harder to learn but more efficient and capable for experts.

  I agree with Mark Marino when he says

  [...] legibility is not dependent on similarity to natural language but overall clarity of expression. That is to say, legibility grows not out of just the syntax but also the phrasing, indentation, and, in many languages, other uses of white space; not in individual tokens but from their use in a system. (Marino, M. 2020, Critical Code Studies, page 144)

  I agree that if something can be expressed in whatever the programming language equivalent of plain English is, then it should be. But I don't think that means the language should use "equals" instead of "=". Verbosity slows comprehension.

  I've always thought it was possible to write bad code (incorrect, obscure, inefficient, etc.) in any programming language.
• Titaÿna

  February 26

  As a former master's student in digital humanities, I took a class on interactive fiction and would like to chip in with my personal experience with both Inform7 and Ink.

  Inform7 has a syntax whose really close to natural langage, embodying the argument for programming languages that emulate natural languages to enhance code literacy. It’s unique in its approach to programming syntax, using natural English sentences to define the game world, its objects, and interactions. For some of my peers it was appealing to them, especially those who encountered difficulties with traditional programming languages.

  For me and others juggling traditional programming classes, things got a bit tricky. It still had a specific syntax to understand while also being a programming tool, which was somewhat confusing. While Python shares similar logic and methods with other languages, Inform7 kind of operates in its own world of logic. To cite this critical review of the program :

  Inform 7 uses a custom-built interface that is radically different from the >
  command prompt which is the standard set by years of tradition.
  Instead, the player (styled “author” in the game’s own terminology) is
  expected to type their input into a window labeled only as “Source.”
  Perhaps surprisingly, hitting the Enter key doesn’t cause the author’s
  input to be processed; it is necessary to press the “Go” button found at
  the top of the screen.

  I ended up using Ink, which also is trying to be close to natural langage but is simpler in syntax than Inform7, resembling more traditional coding practices. So in my experience, which is obviously tinted by both the context and my personal journey, showed me that while natural language emulation can make code more accessible, it can also obscure the logical structures that underpin programming in a very broad manner.

  It echoes the point made by @anthony_hay about how simplification can sometimes overshadow efficiency. In response to the question about code legibility, it's worth noting that good programming practice usually values one-to-one equivalence. This principle is central for any source code, especially when its primary purpose includes maintenance, regardless of the programming language. The equivalence point for me also tends to fall more under the scope of the quality of the code.
• JasonBoyd

  February 26

  @martinbartelmus Thank you for your comment. I think you have picked up on something that I probably needed to develop further: the connection of sonnet to IF. Does the knowing one is 'playing' a sonnet enhance one's enjoyment of SPP as an IF? I think while knowing the sonnet as code helps ones understanding of how to play the IF, it doesn't necessarily enhance one's enjoyment of the IF because the IF's meaning ultimately depends on the message of the sonnet rather than being a meaning that emerges independently through play. That is, I'm not sure the IF tells a story on its own terms, unless it is to the extent that it contradicts (paragraph 33) what I've taken to be the meaning of the sonnets. (I hope this make some sense.)
• JasonBoyd

  February 26

  @anthony_hay Thanks for this very sensible comment. One way in which I might respond is to ask whether its possible (or worthwhile) to not look at programming from a (I assume conventional) perspective of a programmer, where things like parsimony and efficiency are key, but rather from the perspectives of say a essayist or creative writer. It seems to me that getting confused by a function that can be called both 'delete cell' and 'erase cell' can only happen when one ignores that, in English, 'delete' and 'erase' are synonyms, and only pays attention to an abstract external rule that states that a function must have one and only one name. As a writer in English, the existence of these two functions together would not puzzle me, although I might wonder what motivated the writer to use 'delete' or 'erase' in any given context.

  I imagine this all sounds terribly impractical and dilettantish
• JasonBoyd

  February 26

  @Titaÿna Thank you for your observations. As I suggested in my response to @anthony_hay and as I suggested in my critique of @markcmarino arguments in the essay, what I would like to see is a discussion that critically interrogates (rather than takes as a given) the traditional notions of 'good programming practice,'--that asks for whom and in what contexts a programming language is 'transparent' 'efficient' and 'legible,' and whether there are other values that could apply to programming that are closer to what we value in writing in human languages.

  I must I find it hard to compare Ink and Inform 7--there approaches to storytelling are very different!
• leeto

  February 27 edited February 27

  I'm struck by the second question about "programming languages that strive to emulate 'natural languages' so that code literacy does not require a highly specialized literacy far removed from the common literacy that most people possess." It makes me think about languages like python and frameworks like Processing/p5.js, perhaps particularly working in Python. And yet I remember trying to learn to code and feeling stuck when not being able to get a particular dialect of BASIC (FutureBASIC for Mac) working correctly, or when working in Python and getting snagged on syntax and system requirements and Python 2 vs 3 problems. I guess what I'm trying to say is that even when working in languages that attempt to emulate natural language there's still the brittleness of code that can trip someone up. What helped me to work through this is the plethora of tutorials and videos as well as online fora that exploded in the 2010s. Perhaps the easiest entries to programming that I tried out were LOGO and what I found more intuitive: Scratch. I would say both attempt to emulate natural language to some degree, but I found the discoverability aspect of Scratch (at least as much as the block-based system) to be the friendliest onramp of any of the above languages or frameworks, and that discoverability or the ability to hold all the needed parts in your head or how to get at them potentially feels as important to me as emulating a 'natural language.'
• martinbartelmus

  February 27

  @JasonBoyd Thank you very much for your response! I find it very exciting how you emphasize that a kind of enjoyment that arises precisely from the tension between sonnet and IF.
• JoeyJones

  February 27

  Natural programming languages use ordinary words in much the same way as the philosopher Hegel does. The sentences might have a surface readability, but the terms all have some specific technical meaning that can lead the reader astray. Consider this typical passage in Hegel's Science of Logic (Hegel, OUP, 1892):

  Measure is the qualitative quantum, in the first place as immediate,—a quantum, to which a determinate being or a quality is attached. Measure, where quality and quantity are in one, is thus the completion of Being.

  'Measure', 'quantum', 'completion' and 'being' all have meanings that are distinct from their ordinary language meaning. This consistent repurposing of ordinary language for unordinary ends ensures that conceptual confusions will arise easily among readers, it makes the text less legible.

  Well devised natural language programming languages such as Inform 7 can allow the skilled writer to achieve greater unity between the ordinary meaning of a term and what the compiler will 'understand'. We can see that in Scarlet Portrait Parlor:

  Inside the Lair are portraits left to rot
  

  The reader understands that there are portraits left to rot in the lair, and sure enough if the code is compiled then an object called 'portraits left to rot' is created in the room called lair. This tension between the expected and implemented meaning is skillfully used by the author of the poem with "The heavy guilt is carried by the player", as Jason Boyd explores in the article. Here an item called heavy guilt is literally carried in the player's inventory much like they would carry a wallet. (This use of inventory has been taken up by various interactive fiction authors, having a wholly figurative item in your inventory may be unexpected but as a device it is not unheard of.)

  Unity of the ordinary language appearance of code and its actual or intended effect as code requires not just a more expressive language than FLOW-MATIC, but also a skilled author-programmer who can express themselves with clarity in the language. When that clarity is there, we can have very well-formed code that also does what the lay-reader would expect it to do.
• JoeyJones

  February 27

  This possibility of leading astray can be seen in action in Poetry as Code as Interactive Fiction:

  there is no essential problem with programming languages using synonyms for the same operation (“carrying”, “holding”)

  You would think that carrying and holding are synonymous, and in many situations they are, the exact behaviour isn't described anywhere in the Inform7 documentation. However, programmers of Inform 7 and readers of their code can be led astray here, as "holding" encompasses wearing and incorporating an item as well as carrying it, as the following code demonstrates:

  Place is a room. "[if the player holds the hat]You are holding the hat.[end if]
  [if the player carries the hat]You are carrying the hat.[end if]"
  
  The hat is a wearable thing carried by yourself.
  

  We see in this transcript how the two near-synonyms can lead to different behaviour:

  Place
  You are holding the hat. You are carrying the hat.

  --wear hat
  You put on the hat.

  --l
  Place
  You are holding the hat.
• aschwarz

  February 27

  As a software engineer I would take exception that the domain of software development and linguistics and interpretation are different. To Anthony's point, the difference between using delete_cell and erase_cell are a contrivance of the developer in explicating different modes of elimination. It might well be that there are two contrivances, not one, and each has an independent and non-overlapping programmatic universe in which it works. To Jason's comment of the linguistic similarity between 'erase' and 'delete', that similarity exists in a world where precision of terms are valued in a different manner than programmatically. To the point that 'it makes no difference', it is possible to provide two functions in a programming language with different names that have an identical semantic interpretation. Since the world of linguistics and programming are different, with differing objects and drawing differing conclusions, the separately named but identically performing functions may well bring about the poetic content of the code. But to the programmer where precision is held differently than poetry, it leads to confusion. And this confusion is compounded not only to the developer, but to all who view it from the a program's perspective.

  It is an undeniable truth that ambiguity and imprecision leads to some our greatest works of art and poetry. We would be impoverished without this clever formulation and use of words which have multiple meanings, to draw the mind to exploration of these meanings and the truth of the work. But this has so far not been the goal of programming, where precision, that is, uniqueness of semantics becomes one expression of good programming. And indeed, academic teaching of programming teaches that there is a 'goodness' relation between 'good' programming and functional uniqueness.
• aschwarz

  February 27

  To ieeto

  You bring up some interesting notions. One's that have made me readdress my notions of programming, and to come up with some thoughts about programming and programming languages. Your comment about "programming languages that strive to emulate 'natural languages' so that code literacy does not require a highly specialized literacy far removed from the common literacy that most people possess." from Jason and your examination of you own experience introduces the notion of programming languages and what master does it perform for. Your expansion of thoughts into what constitutes a good program that does not require program literacy is perceptive, and brings up thoughts of what supports, and does not support, this notion of literacy in programming.

  We are looking at program languages in isolation, without observing those things from without that influence the languages, and their practitioners. Let's look at mathematics first. In order to understand mathematics we do not require and do not assume that there is a mathematical analogue not requiring an understanding of mathematical reasoning and mathematical symbology. There is no thought that mathematics should evolve into a literary format in which it is easier for non-mathematicians to perform. I might mention that historically the description of mathematical concepts was made in just this format. A mathematical thought transcribed into 'natural' language to express this thought. In this age we find that literacy in language makes a literate interpretation of mathematical thought tedious, and we find the historical precepts of mathematical thoughts in literate terms difficult.

  I assert that programming languages have the same characteristics as mathematics. There is a specialized form of thinking requiring a specialized formalism (the computer language) for expression.

  Languages which tend to reduce the linguistic separation from 'speech' to 'programming' also attempt to maintain some precision. The languages developed to be more akin to 'speech' also have certain rules, and these rules are precise. We can 'write' a program in what appears to be a literary linguistic form but at the end, the program so written must contain within it some coherency of expression and precision of meaning, i.e., it is a computer program.

  Python, to my understanding, and languages like Python reduce some of the programming angst by reducing some of the stumbling blocks in normal computer language acquisition. One such issue has been the requirement that there be a static relationship between a variable, an object which can contain a value, and the type of value it can contain. That is, you define a name, and associate the name with it being an integer, or a real number, or string, or any one of other types. This can lead to boundless confusion for those beginning to program, and yet, in order for the program to be executable this is just the type of determination that has to be made. And so, Python is interpreted with dynamic association of variable 'name' and type.

  Let's call the static type a primitive, that is, it is a fundamental part of the computer operation or the computer language. There is no definition more 'atomic' than this primitive, it can't be deconstructed further. I wrote an API which makes use of this concept (https://www.gnu.org/software/gslip/). It is meant to be a graphical programming API to C++ programs, and is modeled after SLIP in ELIZA's MAD-SLIP interpretation. And yet, it is difficult for a non-programmer to understand, and the description of a 'graph' is a mathematical concept, not a programming one.

  Natural languages have imprecision and ambiguities which must be translated into precision and certainty. Languages serve to implement algorithms. A natural language computer language must be able to express this algorithm in such manner that it has an efficient implementation. Algorithms, and their explication, are given mathematically, graphically, constrained and unconstrained, and represent a rigorous thought process. A computer language written in a literary format must be expressive and able to describe what needs be done.

  So my thought is that computer languages, their development and use, is a discipline. And much like mathematics, this discipline requires some training and understanding, and because of it's peculiarities, it is in general not suitable for developing an 'easier' language in natural language except for very limited purposes.
• brianarechiga

  February 28

  Your question and write up are really thought provoking. Reading your article, I appreciate how you interrogate the false dichotomy created between code and literature (or in a broader sense, programming/natural languages). The Scarlet Portrait Parlor really is a great example of how code is literature and literature is code.

  Your piece along with the comment by @ranjodh made me think more about how this binary between code and literature and notions of code legibility have only been further complicated by LLMs like ChatGPT which can act as an intermediary between natural language and programming languages.

  In one way, we can think of LLMs as an intermediary between the natural language and programming languages. For example, anyone can now ask ChatGPT to “make a program in C# that takes the square root of a number the user inputs.” The output will then be code written in the familiar non-natural language of programming. For some, this act bridges the gap between natural language and programming - like magic, my words are turned into programming languages. It is an act of translation. Additionally, I can ask it to translate a piece of code into natural language if I need help understanding something. Though this, the user can get a sense that LLM’s occupy that the grey area between natural/programming languages.

  However, from a different angle, coding with ChatGPT also reinforces the binary between the ‘natural language’ and the ‘programming language.’ One way we can see this is through the user interface. When one wants a code response from ChatGPT, the code is always presented in a black box with different formatting and easier options for copy/pasting. It is made very apparent that this is a ‘different’ language than the natural conversational part of ChatGPT’s response, further implying that the code serves a different function than the natural language and deserves special presentation/treatment. Through this, the user is taught to think of code and natural language as separate things.

  Now, what is so fascinating about natural language programming languages is that they are an uncompromising example of the arbitrary nature of binary between literature/code or ‘natural speak’/programming speak. The natural language is a functional piece of code and the functional piece of code is natural language. There is no need for that intermediary, ChatGPT, because that grey area that ChatGPT occupies has been destroyed. I do not have much experience coding or reading natural programming languages myself, but your piece has made me much more interested in the work they’re doing, which definitely warrants critical attention.
• jeremydouglass

  February 28 edited February 28

  @JasonBoyd re-reading your article I do feel that your call was prescient and is very appropriate to this historical moment. NLP efforts such as Inform 7 are the culminations of multi-decade projects in specific domains, but it is possible that new hybrid approaches to NLP are becoming possible with that could drastically lower the barrier to entry -- not just for the users, but for the developers creating and maintaining those toolchains.

  @JoeyJones your example of subtle differences in carrying vs holding is a good concrete example how NLP languages such as Inform 7 can have a very strange learning/difficulty curve -- with a very gentle onramp followed by an extremely steep jump that requires sometimes-counterintuitive understanding of complex internals of the world-model and order-of-execution. My students are often surprised at the ways that Inform 7 can get very hard very quickly once they move beyond objects-in-rooms-with-doors.

  @brianarechiga regarding your interesting point about ChatGPT code formatting:

  When one wants a code response from ChatGPT, the code is always presented in a black box with different formatting and easier options for copy/pasting. It is made very apparent that this is a ‘different’ language than the natural conversational part of ChatGPT’s response, further implying that the code serves a different function than the natural language and deserves special presentation/treatment."

  This is a great point that it is the default rhetorical presentation of code in LLM interfaces and that this frames code in a certain way for all users. I'd add that this discursive convention (e.g. ChatGPT almost always types markdown code fences with three backtick tokens around its code samples without being asked and this is pretty-formatted by the web interface) is also just a default convention, and the language model is plastic enough that a user can easily "talk it out of" code fencing with a bit of prompting -- or even request that it do the opposite. Here is a quick playful example:

  You are a natural language inverter: a special kind of program that speaks in source code and uses natural language to program. As such, you will respond to my questions with your English statements in markdown code fences and your code statements as plain paragraphs. Here is an example of an interaction. Your English is enclosed in markdown fences with three backticks, your code is not enclosed:

  ---

   
  User: Please give a one line hello world program and describe it.

  ChatGPT:

  Certainly!
  Here is a one-line hello world program.
  

  main( ) { printf("hello, world"); }

   

  Please give me a recursive program in BASIC and describe what it does.

   

  Absolutely! Here's a recursive program in BASIC along with its description.
  

  10 PRINT "Enter a number: ";: INPUT n
  20 PRINT "Factorial of "; n; " is "; factorial(n): END

  FUNCTION factorial(x)
  IF x = 0 THEN factorial = 1: ELSE factorial = x * factorial(x - 1)
  END FUNCTION

  Interestingly when ChatGPT tagged its English as code above, unprompted it also chose a syntax highlighting descriptor--in this case, vbnet.

  Here is a screenshot:

  
• brianarechiga

  February 28

  @jeremydouglass wow, that's so cool. I did not know that you can play with ChatGPT's formatting like that. Now, I'm going to go experiment with it some more.

  These LLMS are much more malleable than I assumed. This reminds me of phenomenon that I experienced when playing Scarlet Portrait Parlor where I did not try certain actions or verbs to solve the puzzle because I assumed the programmer didn't account for it. Then, when I looked up the solution, I thought, "well i didn't know I could do that".

  It seems like these LLMs are just limited by the imagination and prompt engineering of the user (and of course, the limits set by the creators).