In my previous ‘Practical Necromancy’ post, I made the argument why we should toy with history, using the Netlogo agent based modeling environment.
Let me tell you today what happened when I introduced the idea of simulating the past to my first year students. The phrase ‘digital history’ does indeed appear in the title of the course, yet a significant proportion of the class told me during the first week that they were technophobes, that they could post an update to Facebook, but don’t ask them to do anything more complex! You can see how this is a wee bit of a challenge.
The solution though presents itself when we remember the benefits of simulation:
Benefit #1: Crystallization of one’s own thoughts on history. If I can’t express it, I can’t code it.
Benefit #2: To critique the simulation, one has to perform a close-reading of the code, a prime historical skill.
Benefit #3: Seeing where what did happen fits into the realm of then-possible outcomes; a way of assessing the impact of Caesar’s decision not to cross the Rubicon as it were.
I firmly believe that one of the most important benefits of learning to program is that it provides the discipline necessary to engage closely with texts, to take them apart to understand what the author, the programmer, intended to happen. I built my lesson around Benefit #2, but to ease them into the idea, I introduced them to Chapter 1 of Wheelock’s Latin Grammar.
Why Latin?
I’m no Latinist. But even a glancing familiarity with the language (or with any language’s grammar, for that matter) helps to put the student into the correct mindset for dealing with code. Grammar forces us to look at syntax and construction, and how elements combine to create meaning.
The meaning of a word in Latin depends on its function in the sentence. That meaning is signaled by the combination of a root word and a stem. The verb ‘to praise’ has as its stem laud ; the first person in the present tense is indicated by the addition of –o : laudo I praise; I am praising; I do praise.
We spent a considerable portion of that first day working through Chapter 1 of the Latin grammar. The average Canadian student these days has no knowledge of how grammar actually works, so we had a bit of remedial work to do. The idea that word forms change with meaning, that the structure of a sentence – which words modify which others – can be deduced from the forms of the words even when you don’t know what the word actually means was a bit of an eyeopener.
And programming is rather like composing a sentence in Latin. In Netlogo-speak, you have ‘primitives’ that fit together in particular ways (like when in Latin you put a feminine noun with an adjective, the adjective takes a feminine ending to show agreement with the noun); you put these together into a single unit of meaning, called a procedure. In Latin and English, we’d call that a sentence.
We then looked at the ‘Termites model that comes bundled with Netlogo. I hid all of the code related to setting up the world and its displays, and had them concentrate on the main run-time procedures. I showed them how to recognize an ‘if…then’ type construction, and how to know where a procedure started and stopped. Then, I ask them to scan the code, and sketch out which procedures came first, any loops they encountered, to follow that through to the end of the model. They were to highlight any bits of code they didn’t understand.
Of course, at the end of the exercise, lots of the individual bits of code were highlighted, but as a class, they were able to develop the flow chart of how this simple model works. They’d begun the process of learning how to close-read the code of a simulation. And if you don’t know how the pieces fit together, how can you trust the results of the model? If you don’t know how the pieces fit, how can you know what it means?
Let me conclude with some remarks by Alun Salt on my last post:
[…]One of the benefits of computer models is that reading code requires close-reading which is a useful historical skill. Yes it is, but my gut reaction is why learn close-reading for history by examining code, when you could close-reading for history by examining historical texts? The gut is not noted for its large number of brain cells, and this example demonstrates why mine is no genius. Close-reading for code should be simpler. It should be unambiguous and lacking the complexities of meaning that words in historical text have. It’s an easier way of learning the skill that you can then take into more complex situations effectively making a shallower learning curve.
Having examined the way the code is written, my students are now looking at what the code produces, where it breaks down, and what emerges when you let thousands of individuals, interpreting the same instructions under different circumstances, interact. As one student said, ‘It’s kinda creepy’.
(Image cc Beinecke Library
I think that the link you make between Latin grammar and computer code is a very appropriate one. In fact, Ian Bogost has made the argument for providing a classical education focusing on the Trivium, but replacing the study of Latin with that of programming languages. Like Latin, code teaches people how to learn, understand logical connections and analyze a “text” to find out how it works. The added bonus, however, is that you emerge from your studies with a knowledge of computer programming, which tends to be somewhat more practical than Latin.
When dealing with History majors, of course, Latin may actually be a practical skill that they will use later on. I find your method of using Latin as a tool to introduce the fundamentals of code to be a very interesting combination of the two techniques. It also has the makings of a very interesting interdisciplinary class.