Scribe: A Document Specification Language (1980)

Comments

• jeremydouglass

  January 14 edited January 14

  David, your challenge to locate and close-read the implementation of the first software time bomb was extremely tempting -- I hope someone takes you up on it (or you share a hint as to an entry point).

  I went in a slightly different direction, choosing to subsume this productive set of provocations and questions through the lens of your question five ("device-specific output formats" and "media specificity").

  Rather than attempt to run the code on an emulated PDP-10, I set the goal of sitting with the code by reimplementing a version of the parser with contemporary device outputs. The plan was to create a standalone JavaScript web interface which could parse classic SCRIBE syntax then emulate classic Device outputs (e.g. write plain text and re-enact a line printer) while also rendering contemporary formats such as HTML, Markdown, and PDF as outputs: classic 1980s syntax recreated using related contemporary methods (such as a Parsing Expression Grammar).

  To add one more twist, I decided to walk through the SCRIBE User Manual beginning on the first page, evolving the parser by modifying it so that it could parse the examples given in the documentation, accumulating features paragraph by paragraph and page by page, like kind of literate programming morality play. To turn the experience into a conversation, I fired up an agentic programming environment with Codex and did the first three chapters as discussion of specification and features, a paragraph at a time as a kind of human-agent code book club. The first draft results are here:

  • SCRIBE Redux.

  Select a sample from the dropdown -- samples 2.2 through 3.4.1 are all excerpts transcribed from the book and being parsed, not by SCRIBE, but by a JavaScript reenactment. Many things came up for me during the process of trying to remake what SCRIBE says it is, including the voice, e.g. how the "non-procedural nature of SCRIBE typically gives fits to people who have grown accustomed to procedural document formatters." The one I'll point out though is perhaps the most obvious even without doing any coding: the examples for parsing are from:

  • Le Mort Darthur, by Sir Thomas Malory
  • The Soul of Man under Socialism, by Oscar Wilde
  • The Ballad of East and West, by Rudyard Kipling

  The BLISS source files themselves are also bursting with philosophy, skull ASCII art, and comments that overflow of powerful emotions, but there is something about reading the docs into code like this that felt like a unique engagement with what a privatized, closed, and time-bombed program can still mean through its self-generated manuals. And the example-based or spec-based look at what SCRIBE was changed how I thought about it. It really grabbed my attention when, while explaining the mechanics of Insert statements and the @Quotation() command/environment, Reid quoting Wilde:

  The fact is, that civilization requires slaves. The Greeks were quite right there. Unless there are slaves to do ugly, horrible, uninteresting work, culture and contemplation become impossible. Human slavery is wrong, insecure, and demoralizing. On mechanical slavery, on the slavery of the machine, the future of the world depends.
• davidmberry

  January 14 edited January 14

  Thanks for your great comments, Jeremy. Lots to think about.

  You are right to note the quotations in the documents (e.g. user manual from 1978), Malory's Le Morte Darthur. Wilde's The Soul of Man under Socialism. Kipling's Ballad of East and West. These don't look like test cases pulled from whatever books Reid happened to have lying around. They're canonical literature, the Western Canon (reminds me of Bloom 1994, although correct me if I'm wrong but the Wilde is not on Bloom's list? I wonder if Carnegie Mellon had a great books module at the time?). And Reid is demonstrating that Scribe can handle them, can mark them up, can process them, can reproduce them with proper formatting intact.

  

  I think this matters because Scribe arrives at a particular historical moment when humanities computing is beginning to imagine large-scale digital textual archives. The 1970s saw projects like the Thesaurus Linguae Graecae starting to put classical texts into machine-readable form. The Oxford English Dictionary was being prepared for computational analysis (digitalising started properly in 1984). Literary scholars were starting to think about concordances, textual collation, statistical analysis of vocabulary and style.

  

  So, Reid's choice of literature as examples in the Scribe User Manual maybe isn't incidental to this historical moment (1978-80s). Perhaps it aims to stake a claim that Scribe can handle real literature, not just technical manuals or scientific papers. They represent Culture with a capital C. If Reid had used random Lorem Ipsum placeholder text, it wouldn't have made the same argument. Reid needed to show it could handle texts that counted, texts that had literary value, texts worth preserving and reproducing.

  

  I presume that the intended users would recognise Malory, Wilde, and Kipling. They would share Reid's sense of what constitutes literature worth formatting properly. This, perhaps, marks Scribe as a tool for a particular class? Educated, literary, probably linked to the humanities in some way at elite institutions like Carnegie Mellon? The examples can be taken to perform distinction whilst demonstrating technical capability. Which in itself I think is a remarkable historical time capsule of how things were beginning to shift in the way in which we thought about the "digital" and its relevance to culture?
• jshrager

  January 14

  I was at CMU at the moment of Scribe's birth. Many (perhaps all) of my papers and theses were set in Scribe. A slightly interesting culture developed around CMU at that time, of using @(...) markers in our posting and mail. For example: @spoiler(...) or @flame(on)...@flame(off). (I'm not sure how widespread this was, because I was in the heart of it.)
• davidmberry

  January 14

  Note: Scribe was written in BLISS-10 (PDP-10) and then probably adapted to BLISS-32 (VAX/VMS)

  On Jeff's point:

  BLISS easily attracted a following at CMU. It was used for SCRIBE (an early document formatting utility), PQCC (in the Production Quality Compiler Compiler research project), a WATFOR-like compiler, as well as a variety of other departmental and personal programming efforts (Brender 2002: 962)).

  We can also consult the Scribe Pocket Reference to see how flexible and advanced the text processing was.
• davidmberry

  January 14 edited January 15

  I'm wondering if Kirschenbaum's Track Changes: A Literary History of Word Processing (2016) is problematised when we start to look at Scribe, which shows that the category of a "word processor" is a very artificial one. He attempts to carve out a special exceptional status for word processing, but I think it is difficult to avoid the conclusion that something like Scribe meets the definition of "hardware and software for facilitating the composition, revision, and formatting of free-form prose as part of an individual author’s daily workflow... (Kirschenbaum 2016: xiii).

  Scribe can do everything the word processor can do. And in fact, many word processors worked in a similar way to Scribe (i.e. the show/hide style function in Word Perfect, for example).

  I'm interested in whether the "word-processing parenthesis" (to the extent it can be defended as a category) is closing in an age of AI together with the rise of markdown and new text formats. In fact, I'm beginning to think Scribe is an early anticipation of the direction of travel for the post word-processing world, which he calls the "Writer's Workbench" (Reid 1980: 71). This reminds me of the notion of "context writing", as constructing an informational milieu within which writing takes place, which I discuss in Provenance Anxiety: Death of the Author in the Age of Large Language Models.
• davidmberry

  January 15 edited January 15

  A few interesting observations in the structure of the document Scribe: A Document Specification Language and its Compiler

  The "Cast of Characters" (Section 1.3)

  Reid begins his PhD dissertation not with a technical abstract, but with a "Linguistic Note" and a cast of characters. He defines himself, the reader, and the expert (the designer) as distinct social roles. By personifying the software components and the human users, he frames Scribe as a social contract (a drama?) between an "Educated Author" and a "Mechanical" secretary (the persona of his document). Would this literary framing would be entirely alien to a standard compiler thesis of that era (e.g. for C or Pascal)? It reminds me of the use of persona in Weizenbaum's ELIZA and how he thought about scripts. Reid goes on to argue,

  The fundamental goal of the research reported in this thesis was the design, construction, and documentation of a computer document preparation system that offers the same level of support for a writer that a good secretary does. Ideally, the writer would provide only text, and the computer system would correct spelling and grammar and perform all of the formatting (Reid 1980: 9).

  Was Reid was actually trying to create a "LISP-like symbol manipulation" (Reid 1980: 117) inside BLISS, which was a language that had "utterly no low-level support" for strings (Reid 1980: 106). It seems to me that Reid was building a "Humanities" engine inside a "Systems" chassis, which, perhaps, explains why the code feels in such a tension. It was as if the machine was straining to become a secretary.

  2. The "Ice Cream Vending Machine" (Section 2.1.2)

  To explain the difference between procedural (machine-oriented) and nonprocedural (intent-oriented) logic, Reid uses a lengthy, narrative metaphor about an ice cream vending machine and the "trick" of getting exact change for a bus. This is a style of pedagogy, by explaining high-level logic through everyday narrative rather than mathematical proofs it speaks in a different register to a highly technical report. It suggests an audience that values conceptual elegance and "cleverness" over raw efficiency (e.g. the hacker ethic, and Reid definitely placed himself in the hacker category, even though his software was remarkably well produced and designed due to his background in corporate software development). Reid explains,

  If a system cannot be used directly to solve the problem at hand by our just describing the goal to it, then it is at least partly procedural in that problem domain. Sometimes a system can be lured into solving a problem by giving it a series of sub-goals, each of which it is able to achieve, and the sequence of which will yield the desired effect. For example, there is rarely a key marked "tea with cream" on a beverage vending machine, though there is one marked "tea" and another marked "extra cream". By depressing first the "extra cream" key and then the "tea" key, tea with cream can be had. This is a simple procedure requiring little strategy and little knowledge of the internals of the machine in order to achieve a goal that is closely related to the domain that the designer intended for the machine (Reid 1980: 13).

  Sometimes considerable strategy and knowledge of the implementation of a system can be used to coerce it into solving a problem substantially outside its originally intended domain. For example, a certain ice cream vending machine can often be used to get exact change for bus fare, assuming that a supply of quarters is available (bus fare is sixty cents), and that a possibly-borrowed "seed nickel" is available (Reid 1980: 13).

  The Irony of the "Mechanical Slave"

  With the Wilde quote, "on the slavery of the machine, the future of the world depends", Reid is perhaps gesturing toward a claim that formatting is the "ugly, horrible work" of the "slave," and Scribe is the machine that liberates the "Soul" (the Content) of the Author (see Reid 1978: 16). The metaphor of the computer as "slave" is common in ways of thinking about machines at this time – often unconsciously drawing on a system of oppression inverted to become a means of achieving leisure time from mundane work. For example, Christopher Strachey writing in 1954, the computer "behaves as if it were a completely obedient and accurate slave who works with incredible speed, but wholly unintelligently" (Strachey 1954: 25). We might also link this to gender and the assumption that secretaries are usually women, whose work computers might easily replace. As Strachey writes,

  I do not think that the introduction of computers into offices in this way will produce any very marked disturbances. It is true that a very large number of people will ultimately be replaced by these machines – possibly as many as a million in the next ten years – but the process will be a gradual one. Perhaps more important is the fact that there is, in any case, a very large turnover in the clerks they will replace. The majority of these are young women who leave after a few years to get married, so that the introduction of a computer will probably not throw very many people out of work (Strachey 1954: 31).
• davidmberry

  January 15 edited January 15

  The "Forbidden" Manual

  In the "Documentation Goals" (Section 10.3), Reid recounts a fascinating piece of social history. As he developed Scribe, he wrote an "Expert's Manual" intended only for for high-level designers. But CMU students and staff began illicitly photocopying it to access low-level commands that bypassed the separation of form and content. He writes,

  As I began to produce drafts of the advanced manual, which I had tentatively tided the Scribe Expert's Manual, I noticed that often people would steal them from the printer before I had a chance to go downstairs and pick them up. Everybody wanted to be an expert, and owning a copy of the Expert's Manual put you halfway there, even if it was a bootleg copy. As various drafts of the advanced manual got into circulation one way or another, I found that people immediately started using the features described in that manual, even if they didn't need to, just because the features were there. When I subsequently made changes to those "expert" features, such as the database language, people objected violently that their documents suddenly didn't work any more.

  I then embarked on a campaign to destroy all extant copies of the Expert's Manual, in order that I could do further work on the design of the database language without disrupting people's work. Most of them were actually purged, but enough people had memorized its contents that there were still a number of people busily making their own document format definitions and filling their documents with just the sort of low-level commands that I didn't want people using directly in their documents (Reid 1980: 118-119).

  This is a remarkable instance of a developer trying to restrict user's power to preserve the philosophical integrity of his "markup" vision. It creates the subject position of the "Author" as someone who had the computer processing hidden from them. The ideal author, in Reid's vision, should not know how the machine works. We might note, authors, according to Reid, should not have artistic tastes as they should defer to the "Graphic Designer" who has encoded "proper" typography into the database. It is a very structured, institutional vision of creativity (see Reid 1980: i). I also doubt that many graphic designers would recognise their craft as being a bit like a modern SysAdmin or DevOps engineer who define the "Report" or "Article" definitions in the database using the 100 independent variables. The "Graphic Designer" becomes a kind of typographical bureaucrat, encoding proper form into the system. Authors are not just shielded from the machine, they are explicitly denied aesthetic agency.

  I think this links to Reid's Platonic vision of the ideal page (see Appendix B, p. 147). Reid seems to indicate that there was an "Ideal Form" of a page that existed independently of whether it was printed on a low-res line printer or a high-res printer. It is also an example of device-independent programming that allowed the author to focus on the text, not the technicalities of the printing device.
• jshrager

  January 15

  So, this all brings to my mind something I've not clearly understood about CCS. When doing deep reading -- or whatever you call it -- of a book, the book as written is the same thing that the reader reads, so in some sense (that I must admit I only barely get since I'm an engineer not a media analyst) this critical reading actually "touches" the reader. But in CCS it's a very different situation. At CMU -- having been there then -- we all just thought of Scribe as a better paper formatter than troff/nroff. What Brian wrote or said, and his code, meant literally nothing to almost literally any of us since we didn't see the code, neither did we read his rantings -- actually, we did read his rantings on the bboards at the time, but not about Scribe. Probably almost no one except his committee (as far as I know) read his thesis, and I'm sure that no one, including his committee, read his code. So this deep analysis of Scribe and his writings about it are certainly telling us something, but it seems like it has to be tempered/augmented by the user view. Unfortunately, we don't often get the user view because unless you luck out and someone like me happened to be there then, there's no one to offer the user view (again, v. a book where there are book reviews and discussion ad nauseam about most books that would be worth reviewing. Anyway, I don't know how to straddle this chasm, but it seems to me to be important, esp. as I'm reading you writing all this deep stuff about Scribe which was literally to us users just a document processor like all other document processors, but with easier commands. (Actually, I'm not sure that Scribe was that much easier than troff. The big difference as that this was the time of font-capable printers -- CMU was one of the first institutions outside of PARC that had a Dover -- and Scribe was able to do fonts. In fact, your mention of "stolen output" was probably not stolen, at least in some cases -- the Dover's were notorious for fucking up in various physical and computational ways -- not that we would have stopped using them, it was worth these fuck ups for the ability to print complex documents with fonts! But we had a joke called "Helvectica Zero" -- the font that we had accidentally printed our document in when it never showed up! :-)
• jshrager

  January 15

  BTW, to this point: "Was Reid was actually trying to create a "LISP-like symbol manipulation" (Reid 1980: 117) inside BLISS, which was a language that had "utterly no low-level support" for strings (Reid 1980: 106)."

  I used BLISS at CMU at that time. I'm not sure I'd say that I was an expert, but I wrote plenty of BLISS code. I'm a little surprised to see the word "utterly" in that sentence. It was a specific feature of BLISS that it had "no low-level support" for almost any data structure. Indeed, this was a specific design feature of BLISS; The idea was that the user community would build up libraries of data structure manipulation code, which would thence be available for use by others. Perhaps Brian was the first to try to do string processing in BLISS, although this seems unlikely. I can see that whoever was the first to try to work with a given data type in BLISS might be frustrated that it didn't already have that as a built-in. By the time I was using it, it had perfectly fine string processing capabilities -- maybe I have Brian to thank for this?
• JudyMalloy

  January 16

  "The dissertation describes 'parameterising' the document design into 'approximately one hundred independent variables.'"

  So, since each of the many variables in the JavaScript version of my its name was Penelope looks like this (only each variable holds a different text)

  var fine314 = "

  It was almost midnight.
  I had spent all day taping the photos of
  men and women in the bleachers of the Oakland Coliseum
  together in one long strip.
  The floor of my studio was encrusted with
  pieces of tape, half empty coffee cups, beer cans,
  and empty bags of peanuts and chocolate chip cookies.
  I was still wearing the blue and white checked nightshirt
  I wore to bed.
  I stretched the strip of photos across my studio floor
  and stood back to look at it.

  ";

  and I could add a randomize script as an output option in the Scribe word processor, the whole work could have been done in Scribe without using a separate word processor?
• JudyMalloy

  January 16

  (The JavaScript variable code actually looks like this)

  code.png 116.4K
• jshrager

  January 16

  I believe that the variables he's referring to hold things like font definitions, although some of it can be textual (for examples, fixed signitures and that sort of thing). The body of the document isn't broken up into these parameters. (At least as I read this, and see attached example from his thesis.) It's possible that the document was temporarily stored in the database; I didn't read carefully enough to tell whether this is the case or not, but his examples are all parameters like these.
• JudyMalloy

  January 17

  Thanks, jshrager! There may also be an issue here of the not necessarily standard or recommended way that I sometimes use variables in electronic literature authoring systems.

  Scribe appears to have been a versatile program with a flexible clear capabilities beyond what is expected in word processors. Thanks for introducing this, David.

  In defense of Matt Kirschenbaum’s definition of word processors in Track Changes, he separates hypertext, interactive fiction, and networked environments but then after he says “My focus is on word processors, by which I mean hardware and software for facilitating the composition and formatting of free-form prose as part of an individual author’s workflow," he adds that “The functional boundaries among the preceding technologies are of course porous and to a great extent arbitrary...”

  The shift in Track Changes from Matt’s previous elit authoring focus – where "authoring systems" is an often used term -- was surprising. He probably expected issues to arise, although for my part, Track Changes was more interesting than expected.