Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Witnesses and Witness Marks in Vintage BASIC Code
Hi! This thread focuses on the article I wrote for the DHQ Special Issue on CCS, BASIC FTBALL*** and Programming for All. Here’s the official abstract:
In late fall 1965, John Kemeny wrote a 239-line BASIC program called FTBALL***. Along with his colleague Thomas Kurtz and a few work-study students at Dartmouth College, Kemeny had developed the BASIC programming language and Dartmouth Time-Sharing System (DTSS). BASIC and DTSS represented perhaps the earliest successful attempt at “computer programming for all,” combining English-language vocabulary, simple yet robust instructions, and near-realtime access to a mainframe computer. This article takes a closer look at FTBALL as a crucial program in the history of “programming for all” while gesturing to the tension between a conception of “all” and FTBALL’s context in an elite, all-male college in the mid-1960s. I put FTBALL in a historical, cultural, gendered context of “programming for all” as well as the historical context of programming language development, timesharing technology, and the hardware and financial arrangements necessary to support this kind of playful, interactive program in 1965. I begin with a short history of BASIC’s early development, compare FTBALL with other early games and sports games, then move into the hardware and technical details that enabled the code before finally reading FTBALL’s code in detail. Using methods from critical code studies (Marino 2020), I point to specific innovations of BASIC at the time and outline the program flow of FTBALL. This history and code reading of BASIC FTBALL provides something of interest to computing historians, critical code studies practitioners, and games scholars and aficionados.
The FTBALL*** code is in an appendix to the article, and also available on Dartmouth emeritus professor Peter Doyle’s website and the Vintage Basic website.
Here, I want to focus on the idea of witness marks in code. I’ll explain what they are and give a long preamble to ask:
• What witness marks do you see in the code that you study?
• Who are the witnesses to the construction of your code, and how might you connect with them to learn more about the processes of the code’s composition?
Witness marks
Horologists restoring ancient clocks note the little marks and dents in the clock’s workings to see the path of previous restorers, undo the damage they might have done, and replace the missing screws or tiny gears that make the clock function. Those little bits of human evidence in the machine are called witness marks. (I learned about these from the S-Town podcast, which features a horologist and opens up with a description of witness marks.)
One feature of early BASIC’s line numbers is that by looking at the line numbers you can often glean the process of composition from the code itself. BASIC Convention calls for line numbers by 10s, like so:
10 PRINT "Hello World!"
20 GOTO 10
But if I decide later that I don’t want in infinite loop in my code, or if I want to add something else to the message, I might revise my code like so:
5 LET N = 0
10 PRINT "Hello World!"
12 PRINT "This is Annette."
14 LET N = N + 1
20 IF N < 2 THEN GOTO 10
25 END
That way, my code will terminate after printing my introductory message twice.
A code sleuth analyzing this program later, without me around, would be able to surmise from the in-between-10s line numbers that I added those lines in later versions of the code. The line numbers in early BASIC mattered a lot because GOTOs would point to them. Not such a big deal for my little Hello World, but for a program of any length, it would have been a giant pain to renumber the lines. Moreover, interface for code revision didn’t give random access to the code—you couldn’t just see the whole program and line edit it like I’m doing now with my text in my word processor. Instead, you used the I/O console to add lines to the code in the computer’s very limited memory. You could overwrite previous lines of code or add new ones, but it was too difficult to renumber lines. So, these odd-numbered lines serve as witness marks for the construction of the code, and clues to those of us who come afterward, trying to understand how it works.
In reading the code for FTBALL***, written one Sunday by John Kemeny—one of the co-inventors of BASIC—I wanted to see how it worked, but also how it was composed. I can guess, for instance, that the PLACE KICK was added later in the session because of the line numbers:
5001 PRINT "PLACE KICK"
5005 LET F = -1
5006 IF R > .5 THEN 5010
5007 PRINT "KICK IS BLOCKED***"
5008 LET Y = -5
5009 GOTO 1480
So I can see a bit about how Kemeny’s mind worked in composing this program, which is pretty cool.
Witnesses
John Kemeny passed away in 1992, long before I did any research on BASIC, but years after I’d dabbled in BASIC myself, sitting at my Commodore 64 as a kid in the mid-80s. BASIC was everywhere in the mid-80s, as the CCS classic 10PRINT notes. My research on BASIC was, in part, a way to connect with my own early history with computing. But it also connected me with Kemeny, who was an early advocate of coding literacy, a former assistant to Einstein, and by all accounts a genius and a great guy.
It also connected me to Thomas Kurtz, the other inventor of BASIC, and an amazing person as well. Kurtz let me interview him in 2017, wrote me memos on how BASIC was put together, and then, at age 95, once this DHQ article was published, approved my take on it. He was a witness to both the construction of BASIC and my research on it 60 years later. I also emailed with Stephen Garland and John McGeachie, who were part of the Dartmouth undergraduate team working on ALGOL, BASIC and DTSS in the mid-1960s, for some details and clarifications about BASIC. So, to augment the witness marks I saw in the code, I also reached out to witnesses of it so I could understand the environment in which Kemeny wrote the code. Both the witnesses and the witness marks were key to my reading of BASIC FTBALL***.
Questions
This is a long preamble to ask:
• What witness marks do you see in the code that you study?
• Who are the witnesses to the construction of your code, and how might you connect with them to learn more about the processes of the code’s composition?
Comments
Thank you for this paper as well as this exciting post exploring witness marks and witnesses' memories. Could you share with us one or two of the most exciting insights / explanations about the context and environment that the witnesses allowed you to gain ?
Thanks, Valerie! And sure. First, it was just really great to meet these folks who were responsible for the code that I first dabbled with as a kid.
I could also tell how deeply Kurtz respected Kemeny as a colleague and person, and how truly dedicated both were to the accessibility of BASIC.
But perhaps the most interesting small detail was in the interpretation that I made about Kemeny denying authorship of BASIC FTBALL in a recorded session from 1974. I got the sense he was joking because in that audience, everyone would have known it was him. And yet, in the tape and transcript, he says he doesn't know who wrote the program, so the historical record was ambiguous. When I checked in with the folks who were there though, they supported my interpretation--that Kemeny wrote FTBALL, and that he was playfully denying it. So I was glad to be able to talk to witnesses and make the historical record clearer.
Thank you so much @annettevee for sharing these small details that matter so much to reconstruct narratives, to interpret and analyse, and also to give some flesh to our studies.
I really like the metaphor of witness marks but I think that they would have to be handled with care in close reading of code as they may shape the way we read unless we are constantly attentive to programming practice. For example, the use of numbering in basic is not always helpful as many basic systems allowed the renumbering of programs as you were writing, convenient if you ran out of interleaving lines, for example in BBC Basic there was the command RENUMBER:
This means that you could renumber any code in ways that might look like witness marks are being made but are actually an artefact of the renumbering.
I think that increasingly we will need to find (where we can) multiple versions of the code at different stages of development, perhaps stored on paper or magnetic media, and then we can more confidently reconstruct these processes. In the http://findingeliza.org project we have had to rely on paper copies to do this, combined with other published and archival materials to try to reconstruct development processes like this. But finding magnetic media versions would greatly assist in tracing the development. In this sense the witness marks would be seen as the program organically grew in the filing system.
VAX VMS used to have an amazing versioning system incorporated into the file system so that files, such as program code, would be given a version number after a semi-colon automatically. Such as:
For those interested in software archaeology of source code, this would have a tremendous advantage in tracing the development decisions of a programmer, a history of a program through each saved version (up to 32767 versions of a file). It was actually a pretty smart system but as far as I know was not copied into other file systems, sadly.
These version numbers in VAX VMS certainly could be used as witness marks, but I wonder also if comment lines, like REM are also in some sense witness marks?
Great topic @annettevee
To add to @davidmberry 's cautions
Because in using BASIC to write early electronic literature, it would not be assumed that people would look at the code, those of us who used BASIC might not have expected code critiques, and thus we might not have been consistent in numbering strategies even within our own work.
Here is the Randomizing section of TERMINALS, the third file of Uncle Roger. Note that I deliberately used numbers between 950 and 960 as a personal organizing tool.
In the beginning code for YOU!, I used 05 - 08 to keep REM statements together
Here, however in another part of the code for You!, note that line 695 was added later.
Thank you @davidmberry and @JudyMalloy for these code-based cautions! I am fairly certain that RENUMBER wasn't an option in 1965 BASIC. (I would have to dig into my old manual to be sure, but it was very limited.) So it would, I think, serve as a witness mark for this particular program--but not for programs in later BASICs.
One thing about the idea of witness marks is that they are clues. The clock can still be challenging to put back together, but--as I understand it--these little marks can highlight some places to look for how to do it.
I love the idea of finding system-specific witness mark candidates, as you note with the VAX VMS versioning system, @davidmberry. Each language, version, and hardware system would have its own unique witness marks.
Hi, witness marks sound interesting and I'd not heard of them before.
I noticed that they were talking about adding a renumber command to BASIC in 1965.
I've spent my life mostly writing C and C++. These languages allow some scope for the programmer to express their coding style: where to position braces, variable and function names, whitespace, comments and so on. I think the early BASIC may have been more restrictive. Anyway, in a body of code you might see a block that was in a different style to the rest, indicating that a different person worked on that area. (This may make the code as a whole less readable. Large projects often have style guides that everyone must follow. Some may even automatically reformat code before it is included in a build.)
Each file would often start with a copyright notice followed by a list of changes made since the file was created: often some combination of a date, the initials of the person making the change and a terse description of the change, usually just one line. Source code control systems (e.g. Git) now do a much better job of keeping track of who changed what.
Sometimes lines or blocks of code would remain in a source code file, but were commented out so that they did not play a part in the algorithm. Perhaps to try out a fix for a bug. Again, source code control systems make this less common.
Comments can obviously be very helpful to people working on code long after it was first written. I'm not sure if these count as witness marks.
A scholar's interest in 'witness marks' I expect depends on what their interpretative interests are and how they see the code as a text. If you are interested in composition history, then the approach Annette has taken makes sense. If you are more interested in the potential meanings a text contains (or can generate) as a published text, then trying to ascertain authorial intention (e.g., by interviewing the author) will delimit some potential readings. For the piece I analyzed in my article (Scarlet Portrait Parlor), I could have interviewed the author to answer a whole host of questions (such as, 'Why did you place a semi-colon at the end of the final line?'), but I decided to approach the work as a text that was expected to have meanings that did not depend on an appeal to authorial intention.
It would be interesting to think about what is gained and lost in both approaches to interpreting code.
@anthony_hay thank you for this link to the particular discussion about BASIC in 1965. Very interesting!
And I suppose anything that we think guides us could count as witness marks. But I see comments perhaps as closer to witnesses themselves, perhaps, or least when they're straightforward descriptions of what someone was thinking or how the composing process was happening.
@JasonBoyd Thanks for your comment. And yes, definitely--I think there are a lot of ways to be interested in a block of code. And I'm often interested in what the code does, but I think that the composition process is interesting as well. I don't think this is necessarily gleaning authorial intention though--just the process. I'm on record not really caring about authorial intention.
I do think there are different affordances for the methods we look at code--CCS is, after all, a method for showing aspects of code that are traditionally hidden in the focus on code's functionality.
I'd like to link this very interesting discussion to the history of source version control systems. It seems the the Librarian was the first one back in 1962.
Today programmers tend to use VCS like Git for pratical reasons, but this in turn make it possible for scholars to do this kind of diachronic studies on codes. But Git exists only sice 2005. CVS - no more used, as far as I know - was there from 1986.
Software Heritage project from INRIA aims to try to preserve (open source) codes from different repositories to ensure that this possibility will be granted in future.
(Note: I have tried to do this kind of diachronic analysis on some of my own codes, rewritten more than one time, but I'm not sure that this is a scientifically sound practice... in any case, it poses some question).
@Stefano Wow, that's cool to think about the history of VCS, very meta: how version control has changed over time.
I worked for a short time in the game industry circa 2000, and they used Microsoft Visual Source Safe. My husband (who also worked there) says that they later used Perforce, which is still around, and is better for huge binary assets that game devs need to track.
Not relevant to games in 1965 though!
Apart from line numbers and, for more recent code, source control commit history, the actual naming of objects, methods, functions tells us much. Often we can look at a piece of code and see what Brian Kernighan called Complexity Creep, where code becomes harder to understand and maintain over time. When code's behavior no longer agrees with the central metaphor the method's name describes, or methods have been added in contrast to their object, it can sometimes be quite easy to see what code came first vs what code came later, how someone attempted to tame that complexity, as different archeological layers.
Relatedly, when I "view source" someones' webpage or interactive web-based projects, I often enjoy seeing and learning from their commented out code (particularly commented out console.log print statements).
In regards to the great discussions above, I was curious what else could be considered like a 'witness mark" in other languages, and Daniel's discussion of complexity creep, function names and the like definitely seems to go hand-in-hand. It's relatively rarer to come across Forth/stack-based languages in the wild, particularly here, but that's one where you could almost recreate the history of a program through reading its defined 'words.'
Thank you for your framing and questions. I think the addition of command lines to include comments is an important shift in witness markers. Not only can coders add additional language to read and note their code, but it also acts as a witness marker alerting themselves or others in how to participate in the creation of code and how to further edit or continue and adapt the code into another form.
@leeto I am not familiar with Forth at all, so that's very interesting to learn about. I really love the idea that the program itself would yield its history.
@Temkin yes--so great that you brought in Kernighan here, and the complexity creep. This is of course one of the main reasons programmer want to rewrite codebases when they're introduced to them! Sometimes it's easier to start from scratch than to try to understand the palimpsest of previous writers.
@Slavica_Ceperkovic I do think that comments could be thought of as witness marks, although they would generally be explicit ones, rather than the implicit ones from the original metaphor in clock restoration.
I like the idea of witness marks as class of information in source code that is material yet incidental to the execution of the code.
For line numbers in BASIC -- three lines could be numbered 10, 20, 30, or 1, 2, 3, or 10 15 20 and the three lines would execute the same, making the numbering a (potential) witness mark.
@leeto gives the example of commented out code lines as witness marks, e.g. commented out Javascript console.log statements for quick inline debugging. Again, the line could be there or not and it wouldn't affect execution. This suggests to me that witness marks might be either a companion to or a superset of code comments in general, which are usually by definition non-executed tokens.
@anthony_hay mentions "style" in C-like languages, and many of these elements all depend on the use of (arbitrary) white space that is ignored by the compiler: so, for the example of braces, not whether to use them (you must), but e.g. whether to put an optional line break before an opening brace or not, or whether to outdent a closing brace. A single piece of code with mixed style may bear witness marks -- although code linters are excellent and scrubbing these away. By contrast, in the esolang Whitespace, tabs and spaces are executed -- so they aren't witness marks.
In languages such where you define a 2D array / matrix...
...there are a variety of (slightly self-indulgent) ways to use whitespace to pretty-format a 2D array / matrix so that it resembles a column-aligned spreadsheet when viewed in a fixed distance font.
You find it sometimes in e.g. configuration blocks (or as a whitespace padding function in specialized data editors for e.g. CSV data or markdown tables). Code generators don't generate code like this, and linters will almost universally strip this kind of spacing out, so code lines with spreadsheet spacing have a "hand-crafted" look to my eye--although what is being witnessed may be aesthetics (and perhaps prioritizing code readability over maintainability).
Whitespace can even be witness marks for languages that compile based on meaningful white space, like Python. Another potential example of witness marks that I can think of would be mixed spaces and tabs in Python code. A long piece of python code with short segments indented in tabs and other short segments indented using spaces suggests code edited at different times -- usually via different editors / IDEs and/or by different contributors. While Python 3 disallows such mixing within a code block and throws a TabError, it is allows freely mixing spaces and tabs between code blocks and this happens all the time when code isn't being run through a code linter (e.g. you cut-and-pasted a function from StackOverflow, or switched computers and picked up in another editor with different settings). The mark is not a precise indicator, but it is a trace of something. In dramatic unities (Aristotle's Poetics), a play will have a single action in a single place on a single day; code with traces might similarly suggest ways that it was not a single composition typed at a single IDE in a single work session (although absence might again simply indicate linting).
Hi @jeremydouglass. For fun, some examples of different styles of coding I've seen
Regarding "prioritizing code readability over maintainability:" from my perspective as a programmer code readability is a big part of maintainability. Lining things up in columns sometimes makes it easier to spot mistakes. (One of the downsides is when at a later date a new row is added with a wider field all the other rows must be changed to keep the alignment.) I'm not sure how important the spacial arrangement of program text is to other programmers, but for me it is of utmost importance. Without whitespace to visually group blocks of functionality I'd be lost.
@jeremydouglass
It seems a simple and logical assumption, but...
I've seen different ways of using spaces and tabs (and parenthesis alignment) in the same code, in the same session, from the same author. I can say that because I was watching code behind the coder's shoulder (or in remote coding session), or because I was that coder :-) .
Coders are note heroes. They make errors (they also commit errors...). They are tired, distracted. They are newbies, still deciding which style to adopt. Sometimes they have time to rewrite code and to refactor it, sometimes it's too late and they have to release it as it is.
If you (not really you, but the persona of CCS scholar) expunge errors by default, these facts get lost.
I always try to say to myself a kind of mantra: "code is written by real humans, not by models". And generally speaking, I'm interested in errors and deviations from rules and regulations since the first time I tried to convince the chief of the distance teaching unit in Sapienza University in Rome about the importance of studying styles in code. He said to me: "You know, there are two ways to write code: the correct one, and the wrong one. Informatics is concerned only by the former." I ran away.
While reading another thread about epistemic status of code (with @ebuswell ) I also questioned myself about the difference between studying code as it is thought of by informatics (say: by creators of languages, teachers, researcher) and studying the code as is thought/written of by coders. While the first one is linear, easy to manage, to analyse in elements and categorize, the second one is raw, dirty, full of exceptions. Which one is the real thing? Should CCS dare to take into account also these awful aspects?
First, I just wanted to say that the notion of witness marks is such an interesting analytic for code. I also love the watch-maker metaphor since, like a watch, there is a functional and mechanical aspect to coding that sometimes overpowers the humanity that exist within it.
But I wanted to write out a reply because the idea of becoming a code slueth reminded me of a critical code analysis I did of the imageboard, 4chan, last summer. Looking back, 4chan's code is riddled with many encounters with witness marks due to the fact that it was created as an act of translation.
For some context, Christopher Poole, 4chan’s founder, made the site when he was a teenager and wanted to discuss anime online with his friends. To do so, he used the code from an open source Japanese image board named, Futaba, and made 'American' version of the site by translating its original Japanese code (which was actually a mix of English PHP and Japanese comments) into English using an old site called BabbleFish. He followed the Futaba code so closely that on a macro-level the main functions of the code (the foundational logic of the website) still mirror that of the original Futaba even seven years after 4chan's original creation.
Above is a spread sheet I created. In it, I mapped out 4chan’s function on the left and Futaba’s on the right. The functions marked in red are those unique to 4chan (which vastly outnumber Futaba's). The green functions are those that are present in both of the sites. Here, you can see how closely the logic and naming conventions of the original code was followed.
Even on a micro-scale, if one places even individual lines of code side by side, then it becomes clear that there are some lines wherein Poole simply copied and pasted the Futaba code (a common coding practice, of course).
One can also observe the differences where Poole (and eventually his team of programmers) added new functions/aspects to the code as the site's community grew. There were extra features needed such as security and even upgrading to a more advanced MySQL database system for posts rather than the simple log.txt database system of Futaba. If my understanding is correct, when comparing 4chan to Futaba, the deviations between the two codes can be considered witness marks. Like the line numbers in BASIC, these differences show a certain logic, a certain unique approach the creators of 4chan made. Those choices, while maybe conventional or arbitrary, could still point towards certain insights into the creation/composition of 4chan’s code. What did the creators prioritize? Where did they feel they needed to change due to not only the scaling up of the site (since 4chan grew massively greater than Futaba), but also maybe ideologically/culturally?
One question that might be off-topic, but I have yet to fully grapple with is how are Japanese philosophical notions of anonymity 'translated' through code and introduced to an American audience through 4chan. In other words, what happens when that idea is not only translated from Japanese code into English code, but when that notion of anonymity is introduced into a culture through code?
@brianarechiga This is an amazing breakdown of how the code from Futaba was copied and then modified for 4Chan. Indeed, it does look like the differences are what I might think of as witness marks, showing the process of how it was made and suggesting priorities of design across time. Thanks for sharing!
For your question about the value of anonymity: that's also a fascinating question. I'm not sure I see it as related to witness marks, but I suppose there could be something about the witness marks standing in for the actual/human witnesses in the coding process...? But the fact that anonymity is a value makes it more intentional.