>> Donald Brinkman: Hello everybody. Thank you for coming out today. It is my absolute
pleasure to introduce Nick Montfort. And he's going to be giving a talk on his book, 10 print
CHR string[dollar sign] 205.5 plus RND one go to 10, truly one of the most incomprehensible
book titles, but actually one of the most elegant book titles that is in existence. This book, as
many of you know, is a discussion, it’s close reading in the humanistic tradition of a one line
program on the Commodore 64, which you can see up here, and just, if you haven't noticed
already, this is not an emulator. We actually have a Commodore 64 running on our podium
through a composite video connection. So everything you see here is truly the way the original
works. It makes me very happy. I think this book is tremendously important not just for digital
humanities but also for computer science. And for a couple of reasons, and one is, of course,
that it's applying these techniques of humanistic study to computer science and thinking about
programs and programming languages as languages like English, French, Portuguese, or
Cherokee; they possess a lot of the same challenges and opportunities, and we can look at
them through the lens of art philosophy, you know, translation and other ideas, but also, very
important, is that Nick is not the sole author of this book. This is a 10 person collaborative
endeavor, and it's not an edited volume where each author holds a chapter. This was done in a
very tightly collaborative nature, which is inspiration not just to the humanities, which is
oftentimes where articles and books are written by single author, but even to those of us in the
sciences as a very great, terrific example of close knit collaboration. I'm not going to say much
more, just that Nick is an associate professor of media studies at MIT. He does work in
constrained and computational poetry, computer, he writes computer games, and writes on
the nature of software and society. And so without further ado, let's give him a warm
welcome.
>> Nick Montfort: Thanks very much. So Donald, thanks very much. I am delighted to be here,
and I'm also delighted that after at least a dozen times before and after this book's publication,
speaking about this program, that you are the one person, so far, who has actually pronounced
the title of the book in full in introducing me. So the book is 10 print CHR string[dollar sign]
205.5 plus RND one go to 10. And I want to acknowledge the people who wrote it with me.
The book is by myself, Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mark C Marino,
Michael Mateas, Casey Reas, Mark Sample, Noah Vawter. And I'll talk some about the process
of writing this book and how I think that the models for collaboration laboratory-based work,
conversation, leading to positive outcomes, which people know quite well here at Microsoft
and Microsoft research, they know many computer science departments and other context at
universities throughout the US and around the world, can inform the work that people are
doing in the humanities to connect things like digital media, like code, to culture and the world
around us. And to understand these better in those contexts.
So I mentioned a few things though, to begin with about who my collaborators are, how it was
that we met, posted this program two years ago at the critical code studies workshop that was
online, and these are these collaborators of mine are the people who responded, for the most
part, to my call for discussion about it. People looked at computer programs and thought that
perhaps if they were provocative, if they were something a queried database of potential
terrorists or if they related to different work processes and this was very visible and comments
and variable names and other aspects of the program, then, in that case, they might be
interesting. These may be the programs that we focus on. And so I put this program out as a
very short program, which doesn't have any comments, it doesn't have even any variables and
variable names. We don't know who wrote it; we still don't know if it has a corporate author,
which is Commodore Inc., but we don't know the person who wrote it after writing the book. It
doesn't do anything startling or threatening or any more provocative than presenting a visual
pattern. But we were interested to investigate it and we found that there was a lot to say. In
fact, about 300 pages’ worth.
So I worked with people including the librarian, a sound artist, some people I collaborated with
before, including one person I've written a book with before, people who are artists, you know,
working internationally, co-creator of the processing language, Casey Reas, he’s also the one
who designed the book. And many other people who are academics in my field of digital media
and working as faculty and different places throughout the US. So I do want to mention that if
you're interested in reading the book, if I don't blunt the interest that you already expressed by
coming here in my talk, that you certainly can pick up a beautiful instance of the book itself, but
you can also download it, we made it available at 10Print.org. And it's available there as a PDF,
and we had hoped to be able to share the book just as freely as its original program was shared
with other people and the ways that it was transformed and thought about and the ways that it
provoked people. We hope that our text would do some of the same thing. So let me ask what
reaction you have to the output of this program? What word, phrase might come to mind,
what concept?
>>: Nostalgia.
>> Nick Montfort: Nostalgia is a good one. Nostos algos. People that ache of homesickness,
you know, and so that's certainly one of the aspects. That's a way that people have looked at a
lot of really gaming experiences and home computing experiences. That can also be a way to
dismiss things that are interesting about maybe this as a program itself and aspects of that time
and aspects of computer experience, right? So we can certainly think about this as nostalgic.
And this is a program that I, myself remembered from my days using a Commodore 64. When
we started working on this project we didn't have a printed source for this program; it's just a
version of it that I knew, that we started talking about. And it certainly did hearken back to a
time of exploration and a joyful time for me. But I think also we were all interested in looking
at not limiting ourselves to the perspective and nostalgia, of trying to see what it was
historically, not just in our current memory, what it was from a standpoint of design, from a
standpoint of art that might be interesting about this. Are there other words? As to what this
is or what it represents?
>>: Random.
>> Nick Montfort: Random. And is it truly random? Yes, this is a great question.
>>: It's a maze.
>> Nick Montfort: It's a maze. Yes. So, I mean, the idea of randomness here is very interesting.
So this is one of things that we discuss in the book, in fact we have a chapter of the book
devoted to randomness. Now talking about randomness in the arts, the way it worked in
process-based computational modern art, up through considering how it functions in useful
applications in cryptography and in the generation of [inaudible] and computer graphics and
things like this. One of the things, randomness is a really intriguing concept, a very powerful in
the arts and greatly of interest to people in the humanities. But there’s a lot of questions of
what exactly do we mean matter randomness? So there's competing definitions that we might
say the most concise, the link with the most concise program that can generate this pattern,
you know, or we might talk about unpredictability. As it happens, this program, let's see here,
this program is random in the sense that it's pretty hard to guess what the next left linear, right
leaning line is going to be.
If you're just coming up, if I were to break this program, and I were to start running it again, the
first thing it’s going to print is going to be a left leaning or right-leaning diagonal line. Which
one is it going to be? I think we’d have a hard time guessing that unless someone is able to
follow as with an emulator. Right? So in that sense is quite random. However, it is
pseudorandom in the sense that it’s seeded with the same value, this doesn't have a real-time
clock, it's a deterministic sequence such that any time we turn on any Commodore 64 hardware
or emulator and run this program, we'll get the same pattern. That's not destructive of the way
it looks. That doesn't make it seem unappealing. Oh, it looked good before, but now we don't
like it. Right? But it has some utility, obviously, in that we are using other sorts of programs
and we were wanting to test how they performed if we repeatedly run them, obviously it’s a
good thing to be able to have a sequence that is nonregular, somewhat unpredictable, but can
be repeated the same way.
So one of the things that we discuss in the book is a relationship to various artistic practices,
and things like, for instance, why computers generate random numbers at all. I mean, the sort
of cultural model of the computer certainly in the 1950s was not that the computer is going to
be a really good source of random numbers for us, it’s that it would correct compute bills that
we owe and are going to be sent to us, would predict the weather properly, would does all the
sorts of things that involve the correct calculation. Randomness was the first approximations to
randomness are documented John von Neumann, developing randomness as a developing
pseudorandom polynomial counter approximations to randomness in the context of the
hydrogen bomb development.
So it wasn't a playful sort of a dice rolling concept that led us to this type of randomness. The
other thing I would note about this is that this is definitely the sequence of right linear, left
linear diagonal lines. I try to avoid calling them right slashes and left slashes, I mean
backslashes, because this is actually the slash character on the Commodore 64, this is the
character that's used, and this is the other left-leaning diagonal line that's used. And there is
backslash on the Commodore 64, a sort of extended ASCii or Petski character set. So these two
characters that are being generated here are being generated, one might say, uniformly at
random. We pick or at least to an approximation of that. We are picking which of the two
characters will be shown at random. Well, for one thing, we could change that. We could have
them generated some other way. What if I change this .5 to .1 and then run the program? The
pattern is similar in certain ways, obviously, but it doesn't really look like the same jumbled
confusion. What we're getting is that left-leaning diagonal line is occurring nine times as often
as the right; we are still picking from the same set of two characters, but we changed the
distribution. We can change it further if we like. And see what it looks like. We can, you know,
learn by doing. I don't know of any introductory statistics lecture or article that is as compelling
as being able to play with this program for a little bit and see that you keep this set of two
characters, you're choosing the same, you change the distribution, and the visual effect that
you get differs.
So we also might notice though, that in addition to randomness, this program is taking
advantage of a great deal of regularity. We are only choosing among two characters. We could
choose among, if we wanted to, a much larger number. I won’t try to mess this up by going all
the way to 256, but let's look at say 30 more characters, for instance. And we get a very
different effect. Right? So our constraint, our choice of only two characters produces a very
different visual pattern. So we might, this might be appealing in a certain way to us. It looks like
we crashed ultimate three or something maybe. But it's not the same type of effect in leading
the i in particular ways showing longer and shorter passages that we would see here. So having
only two characters and choosing between them, and also choosing uniformly at random,
having a distribution that's evenly weighted, better types of regularity. Another type of
regularity is that all this is happening on a grid. Right? So we're given a 40 character wide, a 24
character high grid of characters. Does anyone notice anything odd about the way these
characters are being produced? Dot, dot, dot. So what's happening here at the bottom is that-
>>: [inaudible].
>> Nick Montfort: Yes. The displace moving them up, scrolling them up two lines, filling in the
two lines, and then scrolling up two lines again. That's sort of odd. And it has to do with the
Commodore 64 having a logical internally represented 80 character line but a physical display
that's only 40 characters wide. And I'll mention some about why it's got that 80 character line
in a bit. But I want to mention a few other things about the types of regularity that we see
here. Obviously your regularity of process, the flow control is taking us back and we’re
executing the same instruction again and again. We have a regularity of the pace or rhythm
that this is output at, right? So this actually, even though it is not something that we found in a
famous gallery, it’s not something that's valorized by the art world, it incorporates some
interesting principles that make a lot of art generated by computer, effective in that it balances
aspects of randomness with a framework of regularity and aspects of regularity. It's making,
actually, it's using here literally, a bit of randomness in the sense of one bit of randomness. It's
only choosing between these two characters, the left and right leaning diagonal line.
So, Donald you mentioned the program’s a maze or a maze [phonetic]. Do we have any
detractors, maze detractors in the audience, people who say this is not a maze? Because this is
a reaction. Okay, one anti-maze. I mean, one position, I don't know whether this is yours, but
one position is that, you know, well a maze is presented as a puzzle that has, it’s possible to
traverse, you can solve it some way, this is a pattern, but perhaps we wouldn't call it a maze.
So the last, the book here is organized with, there’s five chapters and in between each of these
chapters we have remarks that focus on specific code. And the last of these remarks is a
program called Maze Walker, which is basically a 65 line BASIC program for the Commodore 64
that operationally answers this question: is it a maze? It actually takes the image that is
produced, starts on the left-hand side and determines operationally if there is a path to the
right-hand side, one of the things that we can do using computers, using computation to
investigate things. We can generate and test; we can find out whether something is a maze in
that sense or not. So those who find the idea of it being thought of in an offhand way as a
maze as disquieting, we have a program that will show you which of the patterns it produces,
which screens of right-leaning and left-leaning line actually are mazes according to certain
definition and which are not.
But it certainly, we also have a first chapter that deals a lot with the way that, the idea of the
maze is present in Western culture and specifically in computing. Among other things, Claude
Shannon built a robotic mouse called Theseus that was able to navigate through physical maze
spaces. Actually, the intelligence was in the maze and not in the mouse, in this case. It was a
set of relays, it was tripped different ways. We had an early program on the tixo[phonetic] at
MIT called Mouse and the Maze, which presented a maze much like the Experimenter’s Maze,
with the rat moving around in it. And the rat or mouse could, I'm feeling like I'm at Chuck E
Cheese, I forgot whether it's a rat or a mouse, but the creature could go around and consume
cheese, but it could also be given martinis which would disorient it as it moved around. And of
course, mazes are very important in various 2-D and 3-D computer games, beginning with
Maze, A Maze War in the 3-D realm. And so this was a program that, you know, probably had
some specific resonance with things that were interesting about computing.
One of the things though about this pattern is that peculiar capability of it here is this using that
diagonal line. It creates something that is not aligned to the axis of the screen. It's a diagonal
maze rather than an orthogonal maze. And we actually didn't locate in any computer games,
there’s Q-Bird, there's some isometric games and so forth, but prior to this program's existence,
we didn't locate any examples of diagonal mazes that you could actually navigate. Not bad for
a one line program.
So those are some aspects of this related to the maze. I want to mention a few things about
alternatives, other programs that you could write. So instead of using characters 205 and 206,
which are those two lines I showed you, you could use, for instance, characters 195 and 196. In
fact, we could see what the set of characters looks like, what the series of characters look like
between 195 and 198. And interestingly, they are all horizontal lines like this. So we can
modify the program to print any of those lines. And as written, it's printing two of those less
often than the other ones. Right? But we could. So one of the things, there’s plenty of ways,
you know, to very trivially, very simply start modifying this program and looking at what
happens. Here's a look at characters 198. That's not as interesting as I'd hoped. We probably
want that back in there to choose between two of them. So here we have what is sort of the
vertical line equivalent of the program except it’s not really equivalent. So when you actually
make a program like this and you see what it is, you realize well, actually vertical and horizontal
lines can’t meet up the same way that the two diagonal lines can. They can’t intersect in as
many points. So this is an interesting pattern, it looks more like something maybe woven and
less like an architectural structure or less like a pattern, like a maze.
So the point of writing such programs, let's see what we can do, that is not something we can
do, there we go. That's my version of Hello World in this format. But we can experimentally
take a look just as an artist sketching might do. What if something looked like this? What if
something look like this, right? We can treat code in this way. As people trying to figure out,
you know, what's interesting about this program, why do people memorize it? Why did
someone go to school knowing this program, type it in to impress their friends and not some
other program that was equally short? Right? Why was this printed in Commodore Manual
and RUN magazine in 1984. Why has recurred again and again separate from references to our
book on the web? Well, we can look at what the alternatives are and can try to determine
through experimentation and through making, by creating these different programs, we can
see what it is about a particular program, a particular bit of code that made interesting. We can
also, and one of the things we did, in working on this program is we can port this to other
platforms. So it would be possible to write this on other home computers, we did this in
several cases, Apple 2 version, interestingly on the Apple 2 we find that the Apple 2 has exactly
diagonal slash and backslash characters, but they don't meet up. So it doesn't actually read as a
maze pattern. It's a quirk of the Commodore 64, this Pestki character set that had these
graphics that allowed it to work this way. You can implement it in Perl and JavaScript. It looks
much better if you use Unicode than if you use ASCii because Unicode has those diagonal lines.
So through working with this program, not just researching it, which we did, not just talking
about it and theorizing about it amongst ourselves as we did, but also exploring it as
programmers, as makers of code, we really came to more of an understanding about how this
particular program was interesting, and we also uncovered some new ways to think about
code, which I think would apply not just to one line hobbyist era BASIX computer program but
to many other cases.
So I mentioned some things about the code itself. Notable is that it's written in BASIC. It's
written in a programming language that John Kennedy and Thomas Kurtz, working with
undergraduates, developed starting in 1962 at Dartmouth College, became very popular in
many computer use by 1976 there were already people were saying that it was like the dialects
of English. There are many different dialects of BASIC which cannot be understood at times.
Mutually. You know things like this. This is before the time of micro computing. These
complaints were already being placed about BASIC. Of course, BASIC also came to the
microcomputer and the major force behind that was Microsoft. This version of BASIC, the
Commodore BASIC version 2 is a BASIC that derives from the Altair 8800 BASIC. Do people
know who wrote this version of Commodore? I won't make anyone testify, but I'm just curious
if people know who wrote this particular version of BASIC on the Commodore 64. There's two
people at Microsoft. Rick Welland was one of them who did the conversion for 6502 in
Commodore 64, and the other person is Bill Gates. So I was shocking my free software friends
by telling them that I was going to be doing my presentation entirely using Microsoft software
when I came here.
And it's interesting to see this evolution that, you know, when BASIC became the lingua franca
of the microcomputer, there were features like PEEK and POKE, which really didn't make much
sense on a mini computer, you couldn't write arbitrary locations of memory when you're on a
time-sharing system, and other people have processes running, right? But they were fine for
the microcomputer and they were effective, they allowed quick access and creative types of
programming. What we see in BASIC, there’s some features of this program itself that are just
here in the line of code that are quite telling. The first feature to note is this ten, this line
number. Why do you need line numbers? You don't need line numbers, as Microsoft's
demonstrated with QBASIC and several other versions of BASIC. You can refer to things by
label, assembling language has doesn't have line numbers, you know, there's other ways to go
about this. But the line number is very handy if you are editing on a print terminal. If you're
using an ASR 33 teletype, which is what was used at Dartmouth in 1962, 1964.
You can use this line number to, this is going to be very impressive here when I show you how it
works with this one line program, but you can type, you know, list a particular line number, and
you can see that line number. If you wanted to you erase the line number, let's see here, I'll put
line 1 in, I want to erase it, I just type one and then is gone, right? So it's actually that type of
line editing mode in a print terminal, that is one of the reasons you have line numbers at all.
But that doesn't answer why you would have 10 instead of one. And that's because programs
need room to grow and to change. When you put a program in, even a one line program like
this, you might want to put something ahead of that line, as I just did. And this program starts
with line 10 is an indicator that these, even these sure programs that are there not to build an
accounting system or not for some mass purpose, even these short programs are always open
to change, play, modification.
So the next thing after 10, actually the next thing is a space. So it's interesting in BASIC, in the
original BASIC from Dartmouth and also in the Commodore 64 version, spaces are optional.
You can just write this entire program without spaces. You could do that. We could even use
keyword abbreviations if you wanted to on the Commodore 64 to make it really difficult to
understand. Oh, this is a nice trick. We want to write this program very compactly. I can just
use a go to by itself. I don't need to use a line number. Why is that? Because I use line number
zero. So if I don't give it a line number it will go to zero. So this is a perfectly good, as I was
showing you here, this is a perfectly good version of this program. And the contrast between
these shows that even when you're writing a program like this that no one is forced to use
reverse Hungarian notation. No one is brought in to tell you how it is that comments should be
made and so forth. There's not an extensive plan here. Even when you have a program very
simple like this someone's still making an effort to make this legible and understandable to a
human being. The computer is almost never the only audience for your program. It might be
you yourself but a later time, it might be others, even in a very simple program like this. And
the nature of spaces as optional shows that even though it takes an extra keystroke to press
that spacebar, people do that so that you can read the program well.
Let's see how this, so this is going to list, so that's how it lists, that's what I typed lists out, it
expands these keywords. And then of course, the thing after this is print which seems like a
very obvious way to displace something to the screen. In 1963, I do not think that if someone
came up to someone else and said, print this for me, and they’d swiveled around a video
display and showed that display emblazoned with a message that they asked under print, they
say, oh, thank you, you printed that for me. We now think that it's, of course, what print
means. But that wasn't what print meant, and that it wasn't what print meant to people who
were building BASIC on print terminals, on ASR 33 teletypes back at Dartmouth. So already,
even though this computer was made less than 20 years after BASIC was invented, already it
embodies these ghosts of the past. You can get away from the history of how technology is
made. Right? You can't get away from the assumptions that people had about how things
would be displayed or made.
So we could go on and we do go on and look sort of symbol by symbol at this, discuss the
maze, discuss randomness and regularity, we talk about BASIC and about the Commodore 64 as
a platform. The Commodore 64 is the best-selling single model of computer ever. It has to do
with, of course, there being many more models of a typical computer nowadays. But the lower
bound is 12 and a half million units of this sold, introduced at 595 dollars in 1982. Very
successful system and Jack Trammell decided he wanted to actually sell a lot of them, which
maybe wasn't the idea that Steve Jobs had about the Apple 2. It was fine to just make a lot of
money off a smaller number of computers. So all of these are factors that came together. Our
discussion we talked about this on a mailing list, we wrote the book together on a wiki, we
wrote programs and talked about them and improved each other's code, look at and analyzed
the output, checked each other's sources, looked at the research that we were doing and what
we were uncovering about this program, and we were trying to develop not only an insight into
code, but also a new way that people working in the humanities could borrow from ideas and
the sciences and engineering about how to collaboratively explore and understand topics.
So I can answer some questions about specifics of the book and this code and our project and
why we're interested in something, you know, as seemingly trivial as this. I can talk about the
writing of it as well as the content. But I'll mention, you know, that basically we have code that
is, however it happens, however it occurs in our society is culturally embedded in various ways.
When someone who is a minority gets turned down for a mortgage because of redlining. That
happens because of a piece of code at the bank. It's not a person who decides, no, I won't put
your application in the first place. That application gets typed in, it goes to a computer system,
and these things are codified. These things are written into systems, and the effects of these
systems, if we have the ability to look at code like that, we would learn different things than we
would if we talked to the people who were turned down for loans or officials of the bank. We
would have new access to understanding how software is working in our culture.
And the nice thing is, that even if we can't get within banks to look at a variety of code that is
there, there are a variety of sources of code that's culturally important that are now coming to
light in all sorts of ways. The University of East Anglia's climate change simulation code which
we are leading people to actually call out individual lines of code in discussions and say, look,
this fudge factor, this proves climate change is false. This is the way the code’s being brought
into political and cultural and everyday discussions now. Diebold voting machine code is
another example. Right? And as we develop better ways to understand the relationship of
code to culture, not to dismiss what it does, not to dismiss things about the processes of how it
together and how to plays out in society, but also to understand the ways that it relates to
people as well as computers. Right? Then I think we are in a better situation for understanding
competing technology as it relates to culture and society. So thanks very much. Let me offer
you some bookmarks and take any questions.
>>: When I said nostalgic, I didn't mean nostalgic in the abstract, like early eighties, I meant
nostalgic for a time we're in the 80s coming at this time, it was still a very [inaudible], so
Revenge of the Nerds, your jocks and nerds, but even among the nerds it was still very, do you
like design or do you like technology? And so something like this as opposed to any of the
characters was the first time I could iterate and experiment and create using code and
experience visually. Right? So there was a response that kind of died off and came back again
when Flash came out, right? But we seem to now have, over the past decade, where it started
getting back into specialization again. Are you a high-end graphics or are you a programmer?
And then this aspect of processing or [inaudible]. So we’re starting to see this Renaissance type
person, but I felt like Leonard da Vinci when I could finally start combining code and technology
then, and a lot of people the last couple of generations have lost that, and we’re starting to see
it again. How do you feel [inaudible] that? Is that destined to be>> Nick Montfort: No. I'm completely with you. I do think that, the other thing is it’s important
to say we are not inventing, you know, the way for people to be Renaissance people and to
combine. We are rediscovering it in some cases. I mean, this computer here, which I don't
usually carry around to give presentations, but, you know, if I want to edit video, I am not going
to use this, I'll use my other computer that I have in my bag. If I want to connect to social
networks, communicate online, I'm not going to use, this is not good for that, right? For most
presentations this is not good, although hopefully it did all right in this case. But one thing you
can do with this system is just turn it on and it takes 5 seconds to start. It takes me 10 seconds
to type in the program that I'm showing you here. And you can run this program in 15 seconds.
You can start modifying it, you can have tried three or four different versions in a minute.
That's something that we don't have and I can't open up other modern computers, start them
up and do that with that much immediate access, that much immediate capability. And I would
say actually, that Microsoft, with a small BASIC for instance, has been championing the BASIC
programming language as a way to do this and has been promoting that more than anyone
else.
There are opportunities to program in processing, in Flash, a lot of the creators, I don't know
that, you know, when I look at really creative things done by teenagers in Flash, I wonder if they
paid for their copies of Flash, because it's not software that's made for kids to play around in.
It’s targeted at a different audience. But I suppose our problems with Flash will be going away
before too long. So I think this is one thing that, this is one of the issues with nostalgia, with
looking back, with an archaeological perspective or a historical perspective, is to say that yes,
this computer is not, you know, generally a better device for us to use in our everyday world
today, but it's possible that there's some things that were left behind when we made advances
that we thought that writing programs was just something that maybe you had to do that. But
you don't have to do that anymore. It's so easy. We'll give you your apps. Do that instead.
And my perspective is no, I mean, there's actually real access that's provided to what
computation can do to how it interacts with visual design, gaming, literary art; and we should
be working to bring that forward, to surface that.
>>: Do you think that it’s moving up, I mean, because we have higher and higher level of
abstraction from the hardware itself. Do think it's moving more to the realm of the aware,
these smart phones now, where they can interact with 100 different APIs and build something
that's, you know, up until maybe six months ago, wasn't even possible. Where do you see that
going? Have you seen into that? Are we moving to a realm where we just type a question and
it understands the semantics of it and goes out, extracts the data from a myriad of data sources
on the fly, and retrieves back the decisions that we want?
>> Nick Montfort: Well, we are always going to have, certainly we always interact with
platforms of some sort and programming, the Commodore 64 BASIC is not programming it in
assembly. And programming your, programming this program in Perl, you know, on the
command line is not programming it in x86 assembly, which by the way, has recently been done
in 10 bytes. There's been some people in the demo scene competing to get smaller and smaller
versions; I got an e-mail from one of them, 13, someone beat me, got it down to 13 bytes. But
there's no way it'll, it’s 10 bytes now.
Anyway, there's so much around this besides just the computational abilities of the smart
phone. Right? So the smart phone, we can make programs on our smart phones, but can we
give them to other people the way we can these? I mean, if I make something, like the Apple
Store might not approve of what I make. You know? So, too bad. I just don't get to give my
program away to friends. You buy a computer, whether it's free software, whether it's,
whatever it's running, running Windows, OS 10, whatever, you can write the program that you
want. I mean it might not be this easy. But you can write the program that you want to, and
you can give it to anyone. You basically have a system because of the nature of a computer is.
Try that on a videogame console. Well, that’s not the world of the videogame console or
economic model of it, you know, whatever else. The smart phone is also coming from a
different sort of economic heritage. So I'd love for my smart phone and everybody's smart
phone to be as computer like as possible, but that's not where I would hold out hope for a
really creative exploratory access to programming and playing with computation.
>>: Other questions?
>>: I'm curious about your collaboration model [inaudible]. What was the starting point? Did
you all start in different places and meet in the middle, how did the iteration go?
>> Nick Montfort: The full answer to that is very long, but I'll try to give you a condensed and
useful one, which is that it was done with a lot of structure. So the very first thing I asked
people is I said, go write 2000 words about something about this that you really, really care
about. The idea being, you know, the thing that you think is most interesting at the beginning
of this and most motivates you is probably going to get worked into the book somehow. Right?
So start there. People were very resistant to that idea. My collaborators said what, we need
some more information. But we ended up, I ended up assigning, first of all, collaborating with
everyone to determine the structure of the book, which it did change to some extent as we
worked, but to determine at least a provisional structure of the book and what topics would be
covering, and to assign a lead writer, not an editor, but a lead writer for chapters, who would
then recruit other writers and put together the chapter with them. We had internal review in
which the chapter that was produced was reviewed by someone who didn’t work on it but who
was within our project. And we have also all sorts of special contributions from people like
Casey, our designer, from people who looked at code and worked on, focused on specific
remarks from people who came in to try to repair things like, oh, this is the very first thing we
worked on, and it looked great at the time but I'm not sure if it fits anymore, we need to revise
it.
So it was not a free-for-all. It was pretty highly structured, and it was structured in a way that
we made up as we progressed through the project. So, in certain ways, in terms of people's
perceptions and the gap between them, maybe it’s looking at Wikipedia, oh, it all just comes
into place. No, actually, there's a lot of things that go on there. But our project was very
different in that it's 10 people, it wasn’t writing in public; we did it on a private wiki and we did
maintain the mailing list and the wiki as ways of working. Sometimes people would grab some
text and go off and work on it individually, in person, or online, but we tried to keep those two
as the focus of our activity. So those are some specifics and maybe answers.
>>: How do they differ from your two-person client ratio off of your previous book? I mean,
what's significant [inaudible]?
>> Nick Montfort: Yeah, so the two person, I’d say that the two person one that, you know,
some of the questions people ask about collaborations are like, oh, did you trade off writing
chapters? And to me the answer to that is not very informative because you can trade off
drafting chapters and then people can go back and substantially revise them and you can work
together and so forth to where you basically have a book that both of you wrote. Or you can
trade off writing chapters and then you're done. You can leave it at that, right? So, and how
did you decide what the chapters would be in the first place? So there's a lot more to
collaboration than those particular steps. The project I did with Ian Bogost, which is Raising the
Beam, is a book about the Atari video computer system, and we did draft different chapters
originally, but we went through, we were working, we were revising, a lot of that book in terms
of the mechanics of it, we met in person several times to work on it, but we also, we wrote it in
markdown and we went on IM and we would just throw paragraphs back and forth. You know,
someone would have the chapter because you don't need to work about the format getting
messed up. So that was mechanically sort of how it was that we worked in that case. And I'd
say, I think the two of us had a pretty thorough total view of everything in the book. And I think
the types of depth perspective and angles that people had were different in this project.
>>: I was a bit intrigued by your kind of out of the blue mention of Diebold voting machines. I
was just wondering to see that fitting into this model?
>> Nick Montfort: Well, I mean mainly it’s just, for me it’s an example of a place where source
code itself has come into the political discourse. The absence of the source code, the leaking of
source code, discussion about whether, you know, based on this source code, whether this is a
reliable way to conduct our democracy, things like that. So there are these cases where, it's not
as if you know where the 10 of us, you know, and a few academic allies are the first people to
sort of bring out this idea like hey, I think code has some cultural relevance. Like in fact it's
already out there, it's being discussed. You know, I don't know if this, when the Hans Richter
case was in Wired Magazine, it was actually punctuated with lines of code from Richter FS
where he had variables like darkness and light and things like that. And basically to show oh,
look at this bizarre, you know, language, that's present in the source code. Right?
So we see, you know, these things are already, it's already there, it’s already evident to people
that this must mean something, but what exactly does it mean? Does it mean something
about, you know, what does it mean about C, that Hans Richter chose that language to write his
file system in. Does it, is there a relationship, you know, what is that mean, I always think it's
interesting, everyone knows that everyone would think, who knows anything about Deep Blue,
would say oh, it's a triumph for IBM, it’s capitalist corporate victory over the Soviet Union and
this chess player and everything and Cold War venture, but I've never heard anyone say like, oh
that proves, you know, risk is the right architecture to use for your chip. Or like this means like
C in the UNIX operating system are great. Right? But why not? That project had those
dimensions as well, it's just some of them were chosen to be highlighted. But surely, you know,
the fact that UNIX was around, that sort of something like Bell Labs produced this and so on, I
mean that's not discussed as part of that narrative, but all of these dynamics are there. And so I
think it's ways to enrich the discourse about things that we're talking about, but we’re only
talking about them at the level of the corporate entities that are involved sometimes and also
to figure out things about how computers model our world. Like what does in terms of climate
simulation, like, it's clear that the people who are saying, who are looking at this code and
saying oh, fudge factor, things like this, or I need to fix this, oh yeah, the presence of I need to
fix this in some scientific code means the entire field is fraudulent, obviously. Right? It's people
who haven't read, no one has any context. They have a red code. They don't know what, that
code is dynamic, for instance. And people are still working on it. To do a research project
means that you continue writing code.
So these are things that if we're going to figure out how to incorporate this into our society
rather than just use it as sort of brandish it to make fun of political opponents or things like this,
we need to look, I think, deeper into it.
>>: What do you think about big data, though? I mean I've been looking at this, and it's
essentially 50-50 cheat probability, but what if all you had was the end result in trying to work
your way back within and develop an understanding of what kind of the genesis of it was, or I
mean we’re logging all these tweets and everything like that, you know, where do you think
that's going to end up going where we have a huge amount of data; are we going to get just
down to a point where we have got a 90 percent probability of making a decision because
there’s such a vast amount of information to mine? And all servers require power, and even
with Moore's law, there’s going to be a point where there's just so much information that it
becomes impractical.
>> Nick Montfort: Yeah. I think there's a lot of big data research. There's a lot of big data
questions that are very significant. I like to say, you know, the 10 of us are giving our answer to
big data is small code. Right? That not only can we look at those issues of big data that are
very popular in the humanities, but we can also consider code, which is von Neumann would've
been told, is data itself, data and code are interchangeable, but we can also look at that level.
So I think there's, I mean one of the things I noticed, for instance, with relation to Twitter,
specifically, right, that some of these very same issues, I never told you why this is 80 columns
internally and logically, but it's deriving from the 1928 IBM punch card. IBM managed to
increase the number of holes on their punch card from 45 to 80 in 1928. This is obviously
before computing used for tabulation and so forth. And that card, along with the teletype,
which also predates computing, these were hooked and computers and became part of the
media, as part of the data storage systems, like related to computers. You look at these, so
looking at the material history of computing here is that something that I would say is very
important in understanding what Twitter is. Why are Twitter messages one hundred and forty
characters long?
>>: Because of SMS.
>> Nick Montfort: Because of SMS. 20 character header and 160 character SMS message. Why
are SMS messages one hundred and sixty characters long? I don't know, maybe one of you
knows this guy’s name, there's a German guy who largely invented SMS as a standard. He
typed things on this typewriter to see what sort of messages would be reasonable. He looked
at postcards. He used an existing medium, right? A material medium where people wrote on
the postcard. And he's like, well, if the message on a postcard is good enough and useful
enough for someone to send, then why don't we have that much text for SMS? Right? So there
are all these material histories behind the length of a Twitter message. Interesting that his
typewriter was probably 80 characters wide, maybe also related to the IBM punch card, and so
two of those would've been 160. But anyway, so these are the types of things like, it I don't
know the answer to the analysis of big data, but I think that it's going to be enriched by
understanding in these sort of material contexts. Right? Not to say that postcards and Twitter
are the same thing. I might send a friend a postcard at some point, but I don't think I would
ever make a choice like oh, I think I'll tweet instead. Like, I mean these are basically a distinct
media, but they're wrapped up in their histories. So I do think that there's ways of relating the
research that we are doing here to big data questions and that’s some of how I would begin. I
would look at the material histories of where those systems came from. There's, as Lisa
Gittleman says in an upcoming book, there is no such thing as raw data. There’s just data that
we have which occurs in different formats and media that are set up in different ways.
>>: There are several comments I’d like to make. Definitely something, a topic that's
passionate to me too, but I guess one thing I'd like to bring up is that it seems like culturally,
you were talking about, you know, code in culture, and what I see is that I see that the idea and
the concept of technology is very, very prominent in culture, but the actual underlying code is
hardly visible at all. And it seems like there's this gap between them that people love using
their devices, they love being on Facebook, they spent all their time online, but they really are
not literate about how that works and what's going on behind the scenes, and I don't know
about a question, but kind of a challenge is what I'd really like to do is to decrease that gap in
whatever way I can. And it really sounds like part of the things you could do with projects like
you're working on is to inspire people to make things like this.
>> Nick Montfort: Yeah, I very much hope to. I'm at work on another project on exploratory
programming and trying to focusing on the arts and writing in humanities. Trying to help
students to see how code can be used as a way to think, sketch, and explore. Not so much, you
know, build a JavaScript PHP slick website of some sort, but actually think through your
problems using computation. These are really important issues, and code was more visible, I
mean you could go to the grocery store and get a magazine off the rack that was full of BASIC
programs in 1984. So that doesn't mean that, you know, that's a superior way to distribute
software and we should go back to it. But it did make it evident, like hey, this is what makes
this run.
>>: I think I'll follow up on that comment and the previous threads is, this definitely was a time
when the ability to create and consume were balanced, right? I mean, you can go to
RadioShack in the 80s and [inaudible] is awesome, twenty go to ten and you walk out and feel
like you hacked the Gibson or something like that. Today, Microsoft does well, but we don't
have, my seven-year-old daughter she can't, she doesn't have the same interaction with
computer that I did, where it was always there. Right? But Khan Academy has been doing
some very interesting things online using processing JS exactly for this thing as well, and I know
you are working with the processing guys. As a teacher, the students that come in, are you
seeing a shift recently from how they were before, I mean do they come in thinking combining
code and design or where is that thought pattern right now are you seeing in your new
students?
>> Nick Montfort: I wouldn't say they do, I teach two categories of students. I was looking for
a, there's a photo in here, which I could hold up, but no one would be able to see anyway,
people any retail store, you know, kids standing around, one of them working, maybe
programming, playing a game on a VIC-20 or a Commodore 64. These were environments
where, in fact, you could just walk up and use computers. There were places like the People's
Computer Company, Menlo Park, storefront space where people went in and wrote programs.
So I teach MIT undergraduates who generally all know, even the ones, programming isn't
required as a course, but everyone in my experience knows how to program basically in my
writing classes where I'm teaching, and then I teach graduate students in comparative media
studies. And some people, they include people who have computer science bachelor's degrees,
but there are also people who have no background in programming who have interest in media
and expertise and background of various sorts, but it doesn't include working with code.
>>: It seems also as if society has shifted, I mean, Minecraft has taken off the system
specifically for the world building, that the closest I can define modern to what it felt like in the
early 80s with code; it’s hearing these kids talk about Minecraft and in their world and setting
up their water systems and it’s exact same fielding and like the other person said, they’re not
thinking about this in terms of code but it’s exact same internal flame, right, but they're just
advanced.
>>: A couple of thoughts. I'm seeing a connection between what you said at several points
through the talk, and Bill Rosen’s, The Most Powerful Idea in the World, are you familiar with
that book? It's about the history of steam power?
>> Nick Montfort: Okay. I’m not.
>>: What's interesting about that, it's kind of a weird connection, maybe, but what becomes
clear is the incrementalism of a very important end result, right, which was the steam engine,
and the steam locomotive, but he traces it back hundreds of years in multiple countries, all
these innovations that had to happen to result in that. And that I see is the same thing like the
way the Commodore 64 works, right? There's influences from punch cards and there's
influences from five or six models of computers Commodore itself made, and that all results in
the final product.
>> Nick Montfort: Yes. This program runs on the [inaudible], runs on the VIC-20, unaltered,
yes.
>>: So anyway, that was one thing. The other thing is that I have two boys, almost ten and
almost 13, and I initially thought that they just wouldn't care at all about my whole history with
Commodores because you know, they've grown up in a very PC centric world, and it's a very
rich world, right, and they're very into things like Minecraft and there's a lot to learn there for
them and a lot of richness; and I was really surprised that they actually have been really
interested. We've got really involved in the retro Commodore scene here locally. And there's
something about these older computers that if kids get exposed to them, they really are
interested in them, and I’m trying to tease out what that is, and part of it seems to be that you
can get closer to the bare metal with them. You can actually, it's kind of like owning an older
car, you can actually understand everything about how it works versus computers now, which it
almost seems like it's nondeterministic because it's so complex you can't really figure out
what's going on. So I don’t know. Just throwing out some thoughts.
>> Nick Montfort: Yeah. I mean, they're great machines. And they're still, I didn't even make
mention of any of it, but there's a huge amount of continuing productive activity on the
Commodore 64. People in demo scene creating amazing audiovisual programs, people doing
SID, you know the sound interface device, Bob Yannes’ SID, there's a huge amount of work
that’s still going on, and it's, I mean, to some extent it’s for some people, I mean it's not
nostalgic. I met a guy who was, it’s been two years ago, I guess, whose working in the demo
scene on the Commodore 64, he's 18 years old. He didn't program on the Commodore 64
when he was young. He came to this machine, found it really compelling and interesting. So
yeah, I think there's a lot to be said for the use of these machines just as a way not only to
understand computer history, but also to just engage with computing and to explore and play. I
am doing a BASIC workshop, a Commodore 64 BASIC workshop at UCLA, so we'll see what the
students there next week will think about that.
>>: Do think part of the appeal is the relationship between constraints and how that seems to
sometimes create this burst of creative energy because of those constraints?
>> Nick Montfort: Yeah. Definitely. But it's also, I mean, every system that we use is
constrained, it's just sometimes more obvious. It's easier to see what those constraints are and
to understand them, you know, when you look at in older system like the C-64. I mean, there's
increasingly there is a lot of amazing work that's done. Last year they discovered a new video
mode on the Commodore 64. So I mean this is like, we actually have, you think that this type of
system, there's some people who are sort of dismissive about this. Like one of the activation
programmers was mentioning about the Atari VCS, he's like oh, you find out how to do
something really new and clever and interesting, but it’s just like finding change under the
couch. You put it there to begin with, and now you're taking it out like it’s not a big deal. But
no, I think there's something, I don't feel like that. I think there's something to it.
>>: So this goes back to some the stuff you were saying a moment or two ago about that sort
of the perception of programming or whether young people program and so on, and I just
wanted to bring up, it seems like you found a bunch of interesting things about the way that
the Commodore 64 was pitched and who it was pitched to, I seem to remember some
interesting old commercials that illustrate programming as a fun activity in a way that it’s not
really considered a fun activity anymore. I wanted to know if you had a little to say about that>> Nick Montfort: That's certainly the one thing I would show if I had hooked up my modern
day computer, would be that Australian Commodore 64 commercial. But you know, you really
had, again, I mean, partly from necessity, but partly as an empowering way to experience
computing, it was foregrounded that you would, of course, program in BASIC. And there were
ads, you know, the Apple 2 ads that said you'll be programming on your first day, and people
would be depicted in print advertisements and video advertisements as programming alongside
other things that they would do on the computer. So this was, I mean there's other funny
things about those ads, like they would often have, the computer would be like set up on the
kitchen table, the family would be around there and you would be like where do they eat now?
You know, it was sort of strange, they weren't quite sure because I mean, there wasn't a place
in the home really to put the computer necessarily already. Certainly not where everyone
could use it, right? So there was sometimes a strange tension in these ads. But they did make
it clear that programming in BASIC was supposed to be for everyone.
>>: The cords and power supplies were always missing in those ads.
>>: Have people’s expectations gotten too high? The thing I was just thinking of watching this
was around this time with Apple 2 and Commodore, you know, you could go get a computer or
even in the store go in type ten print hello and have it run and then you'd say hello, or then
you’d start adding minor things, but at the time, even that was something to brag about. It's
like whoa, this computer actually is doing something. And now I can change it so says, which
way do you want to go and then input X string and then you could put in North and then if it’s
North it’s not like that. And that would be really exciting, your friends would be like whoa, you
created a game. But now, if I showed my son that, he'd be like, so? What's the big deal? And
so is that really what is one of the barriers there because the alternative now, of course, is
okay, well HMO plus JavaScript plus Canvas, but the barrier to entry there is really high.
>> Nick Montfort: Yeah. So I guess you have to ask with programs like these, what does it
prove? [inaudible] infinity, right? But what does it do when you are writing these programs and
when you’re creating an effect? Some of them might be tricks. But in this case, I'd say I tried
this program both ways, right? And what this program, with the two line version of this
program tells me is that it's as easy for a computer to do something an unbounded number of
times as it is to do it once. And that's actually sort of interesting because that's not at all what
it's like for a person, right? So now I understand something, I mean, what is this silly twenty go
to 10 thing adding on here, it's actually possibly giving me some access to something about the
way computers work, what they can do, how I might be able to use them, what I can expect
from them, right? So I don't think these are exclusively trivialities. And I think there's things
about, like being able to put up pages on the web and I wrote a story, I want to put this on the
web, I want everybody to be able to read it, I mean that's, oh gosh, it’s as easy to make this
available to the world as it is to my friend, three doors down. You know, that's a pretty
powerful thing to. So I think there's something behind these things. It is important, I think, to
articulate what it is. And it's not always obvious when you have some program that is trivial
looking or that looks like a trick, but I think there is something behind many of these programs
leads people on to understanding computation better and be able to manipulate it more
powerfully.
>>: I have a question related to yours. You know, when we think about microcomputers and
really the introduction of personal computing in the house, they came with the thought of we
are going to give you this, it's yours, and do whatever the hell you want with it and discover and
explore and share, right? And then we fast-forward to now, and we have really the opposite,
where everything comes out and it says the Corporation owns this and we are going to let you
use it this way and that way and no other way, and do you think that sort of the social impact of
that and how it's cascading and growing is going to have a negative effect on society as time
moves forward and people become less exploratory in that aspect?
>> Nick Montfort: Well I think that, fortunately you're still describing smart phones and video
game consoles more than you’re describing computers, laptops and desktop computers. There
are still a lot of, I mean we may not like certain things about how they work and what happens,
but we still actually have an environment where we can sometimes with difficulty, but we can
create with computers. So I think that's, you know, part of it for me is whether that model, like
I mean, I haven't run into anyone, I think people recognize that smart phones are capable of
general-purpose computation, right? But there are very few people who really would say oh
yeah, I have a right to make apps on my smart phone and send them to people. I mean, I know
people who are app makers who like to do that, but the idea that that would just sort of be
fundamentally an ability. So I think that computers are actually sort of a stronghold of like
people being able to do stuff online and, you know, in a stand-alone sort of load. And that we
should continue to exploit that ability. This all has to do with the fact that when you buy a
computer from Dell, Dell isn't waiting around for you to buy more software for them, from
them, in order for them to make their money back. Like they're making their money when they
sell it to you which is not the way the videogame consoles work, which is not the way generally
that smart phones work, right? And so forth, so there's generally different sorts of issues of
control and exchange that are happening.
>>: Two comments. It's been kind of mentioned here before that I think there's two elements:
one, kids today, you know, they look at search. They take it for granted that they can just go
put it in the little, some stuff into a text box, hit go, and they get back a huge results, that they
don't understand necessarily how it works and they don't necessarily care. It's kind of like in
the Matrix. You don't necessarily know how all the machinery works but you don’t really care
about it as long as it works. The other part is, I mean I work in operations, and for me it's about
scaling myself, and I think that's a lot of where computing is going and what could be lost. I
think that, for me that’s the thrill, is being able to go and what I can do against one machine
building a tool that allows me to have 1000 machines. I can scale myself and that's, the same
goes for Twitter or social media where you have a whole bunch of followers. You're now
popular. And I think that's where it's going. But I'm just wondering where that's going to end
up because I think it>> Nick Montfort: I think is some people would say it would just end up having a number. You
might end up having a number of friends, but not friends. Just a number. So yeah. I think
there's some things and maybe there's some things you can scale being able to administer
machines might be different than having social connections to people, right? And so, not to say
that there aren't great things about the ability of the web to connect people, but these are all
significant questions. And not all of them you would directly address with the Commodore 64,
that doesn't have that type of connection capability and that possibility for scaling up in those
ways, but it can still provide a perspective on pieces of the issue.
>>: So we want to give a little bit of time so that Nick can sign books if people want him to. But
thank you. That's one of the best Q and A sessions I've seen in this room. And yes, please do
talk to Nick afterwards, and he can sign your books. And I was just going to close out, I did
actually find that Australian Commodore 64 commercial. So let's give Nick some thanks and
then he'll be here.
>> Nick Montfort: And also, actually, let me invite you to, well, Donald wants to switch over to
the modern-day computer, but I also want to invite people to come up and use the Commodore
64, make some modifications to this program or type in your own, if you like.
>>: Yeah, I'll play this quick, and then I'll switch it back. So how about that. Thank you, Nick.
>> Nick Montfort: All right.