It’s true, Mark, that platforms are different depending upon the perspective of different developers and users. This is important to any approach that takes platform into account, including mine. As to the idea that my critical approach mystifies computers, it would be hilarious if it were funny. This is a sure sign that the explanation I’ve given on here is far too sketchy to argue against, though.

None of which “means” anything to any machine that might be involved. The notion that anything other than “the human dimension of meaning” plays a role in computation is one that I believe to be very dangerous to buy into, because it mystifies computers, and draws attention away from “the man behind the curtain” (where it belongs, if you want to be able to call yourself “critical”).

There’s no strict dividing line between a “platform” and a “program” though, except perhaps in the simplest cases. Obviously whether it’s in software or hardware isn’t the dividing line, because that’s a somewhat arbitrary decision driven mostly by cost considerations. Among software pieces, some seem relatively easy: The guts of Windows are part of the platform; as are your graphics drivers, the Java virtual machine, and the C runtime library. Are libraries you use part of the program or the platform, though? Whether something is a “library” or not is even kind of arbitrary, and mostly a software-engineering decision. For example, if I write a program that maintains a database of current facts, I suppose my program is keeping track of facts—but if I rewrite it to use a rule-chaining engine like Jess to do the maintenance, the facility of rule-chaining is really part of the platform, along with the filesystem, JVM, graphics drivers, and math library. And in principle nearly everything can be abstracted out into a library, leaving nothing for the program…

See, I created a variant. ;-)

As Matt says, textual studies is a rich approach. It’s not just pretending that things are texts and then discussing them. This approach can be applied (directly or by analogy) to objects of different sorts. In the case of programs, this approach can be applied with concern for how programs function when run on a computer, not just with an eye to their human dimensions of meaning.

Despite the vague, amorphous name of the field, “textual studies” is not just the study of texts in some vague, loosey-goosey kind of way. It’s the specific scholarly discipline traditionally responsible for sifting amongst an author’s papers and manuscripts and making decisions about which version of a text either best reflects the author’s intentions (the old school approach) or else how to represent multiple versions within the limits of a printed book or (more recently) in electronic editions online. Every wonder why you walk into a bookstore to see ten different versions and editions of King Lear on sale? It’s because different scholars have reached different conclusions about what the text of King Lear actually is (note that we have no manuscripts of this or any other play surviving in Shakespeare’s own hand). The point is that in the process of doing this kind of work the discipline of textual studies has nurtured a very rich, mature conversation about the fundamental nature of texts, versions of texts, the ways texts interact with other texts as networks, their material dimension (what does it mean when an author doodles in the margins of a manuscript–is this part of “the text”), and so forth. Without meaning to speak for him, I suspect these are the kinds of insights Nick finds potentially rewarding in the study of computer programs.

You say your project is “to understand programs via textual studies”, while denying that “computer program” is a subclass of “text”. How is this supposed to work? How can the toolset provided by textual studies be applied to entities that are not in the class for which the tools have been developed?

Let’s say you use that toolbox to compare two entities: (1) is Turing’s paper “On computable numbers, with an application to the Entscheidungsproblem”, and (2) is the Linux source code. How will you use textual studies to show that (2) “does” something that (1) doesn’t?

Actually, me saying that “(2) = (1)” is an exaggeration to the benefit of (2), since Turing’s theoretical machine is unbounded with regards to time and memory used, which clearly makes it more powerful than any of its real-world implementations. The fact that (2) has “program semantics” is fully due to the fact that (1) has the “meta-semantics” that are necessary and sufficient to define those “program semantics”. The fact that we now have physical machines which are able to interpret and execute the instructions inscribed into (2) is due to the fact that humans did interpret and execute the instructions inscribed into (1) first. Finally, the fact that no concievable class of digital computers, including yet-to-be-realized quantum computers, is able to exceed the limit posited by (1) is, well, simply one of the best-proven mathematical facts in existence. So, as I’m sorry to say (and I mean it: sorry!), your claim that “digital computers do things that texts don’t”, to me, lacks any foundation.

1) Given that “silicon is just frozen software” (Andy Grove, Intel co-founder), why do you describe “computer programs” as “an important part of a system”, instead of just stating that a digital computer, as a physical whole, is (functionally) identical with its program(s)?

A digital computer is a platform that can run many programs – something important to understand in order to see how platforms influence what runs on them, and to understand the formal and material nature of computing.

2) The “just as” seems to imply only an analogous relationship between the concepts “computer program” and “text”. Why not just say that a computer program is a text?

A text doesn’t have program semantics and doesn’t execute; making this “equation” would be overlooking the (new, interesting) things that computer programs do which texts don’t. Analogy isn’t identity; it’s a connection that recognizes how the analogy highlights certain aspects and hides others.

I’m all for making the connection, but in a way that helps us to understand computing vis-a-via texts, not in a way that collapses essential aspects of the former.

it should also be pointed out that the reverse (a text is a digital computer) is false

Presumably because digital computers do things that texts don’t? I think we may just disagree on what the word is is. I’d like to understand computer programs using textual studies, but not pretend that they are “just texts.”

At any rate, I don’t have a complete theory of how to understand programs via textual studies at this point, but I’ll be working towards in approach that captures something of the important nature of systems and programs, so I resist the “is.”

[...] “computer programs,” as a concept, focuses on an important part of a system, just as the concept of a text provides focus.

I have some questions arising from this:

1) Given that “silicon is just frozen software” (Andy Grove, Intel co-founder), why do you describe “computer programs” as “an important part of a system”, instead of just stating that a digital computer, as a physical whole, is (functionally) identical with its program(s)?

2) The “just as” seems to imply only an analogous relationship between the concepts “computer program” and “text”. Why not just say that a computer program is a text?

3) Putting it together, why not just say that a digital computer is, very literally, a text?

Of course, it should also be pointed out that the reverse (a text is a digital computer) is false; but it sure would have been a great help to me if somebody had made that particular connection for me when I started out with “digital writing”.