No, they shouldn't. At least according to Douglas Hofstadter, who holds Ph.D.s in Comp. Lit. as well as Physics and has published extensively on artificial intelligence. His reasoning? Does making swooshing sounds while holding a toy plane qualify you to be a pilot? (That's exactly how he put it to me in an impassioned message.)
I also object. But not for the reasons Hofstadter gives—that basically human languages are far richer and more complex than computer ones.
UC Davis and UC Irvine now allow students to substitute one “computer language” for a foreign language. Of course I have no objection to studying codes and I believe in a form of AI (connectionism), so I'm not a Luddite. And I'm an object-oriented ontologist. I don't believe humans have a monopoly on meaning. I think humanists should study all kinds of things (“carpentry” as Ian Bogost puts it). In fact, learning how to code might be just the ticket.
No actually my reasoning is quite different. It's that the codes under discussion (mid- to high-level) are very specialized, rigidly formulated versions of ENGLISH.
The reason is obvious: humans program computers and they need to be able to understand the code they use.
If we allow computer languages, we should allow recipes. Computer codes are specialized algorithms. So are recipes.
Now let's go a bit deeper. The term “computer language” is weaselly. Do I speak to you using hormones and neurotransmitters? My body does. But I, Tim Morton, use words. When I speak to my computer, telling it for example to shut down, I use English: I hit “Shut Down” on the menu. How the computer executes that command is withdrawn from me, to use the language of Ian Bogost's Unit Operations. As good posthumanists we should realize that we are in the happy position of already talking to computers all the time—in English. My argument isn't an argument about whether computers can talk.
I'm not discriminating against nonhumans, just as using words to talk to your friend isn't discriminating against hormones. But hormones are a “human language” as much as software code is a “computer language.” I fancy that the term “computer language” is used to make “computer” sound like “French person.” But “computers” are no more “people” than a bunch of hormones are French.
Again, what we're really talking about is software code. I believe that if we announced that we were allowing students to “translate software code” there would be an appropriate (negative) reaction.
When we examine software code, we find phrases like “listproc.” These are highly abbreviated, encapsulated forms of English, like “i.e” is an abbreviated form of Latin. If you want foreignness you should go to the machine code level.
So what are we doing when we ask a Ph.D candidate to “translate” some software code? I hold that we're asking her to do something very different than what we want when we ask her to translate some Derrida from the French.
We are asking her to parse a very rigorous set of algorithmic instructions into a less rigorous form of the same language. (That's the funny thing: the real difference between human languages and software codes is that the former are sloppier and less rigorous.)
Allowing students to substitute a software code is unfair—mostly for the students who haven't chosen this option. They have to translate a different language into English.
.
This strikes me as pretty similar to maintaining that mathematics is just a specialized form of English because, in math, we use words like "equals" or phrases like "as n goes to infinity". (Or, if we speak another language, we use phrases in that language.) The same argument also establishes that source code is in all languages simultaneously, and all natural languages are identical, so it's somewhat self-undermining.
But in a programming language the only strings over which the programmer has no control are the reserved words of the language, which may be very few in number, and which themselves needn't be in (or related to) any language in particular—their semantics are independent of their textual representation. Names the programmer introduces are, optimally, related to what the named will do in the program but to the extent that that's the case it's a help to the programmer. But of course one can do without that.
So, yes, it's true that when we look at source code, we see descriptive names, which, being there to help the programmer, are or are related to terms in the (natural) language the programmer knows. If we had no idea what a name meant, we could still figure out what was going on—if we knew the programming language. The names could be in, say, French. Even the reserved words of the language could be French-like. Thus, this source would count, I suppose, as being in French. However, if I document the program in English, I am, apparently, simply moving from one form of the same language to another. Since I'm writing in English, however, we have English being the same as French. (I needn't know French to be able to do this. I need to know the programming language.)
Of course, if the process of explaining a bit of source code—"translating" it into a natural language—were really that of describing the algorithm in natural language, that needn't make the result any less rigorous. There is even a term for a sort of halfway house between ordinary English and programming languages used for describing algorithms: pseudocode. (If you really wanted to get into the nitty-gritty in your description, though, it would be disastrous; it would be like providing the sort of translations linguists sometimes do: rendering "ihm schenkte ich das Buch" as "him-DAT give-PRET I-NOM the book-ACC".)
The proper analogy isn't to recipes, it's to cooking. I don't, as it happens, think that students should be able to substitute learning how to cook for learning how to speak English. But I also don't think that in learning how to cook they'd just be learning a form of English. Nor would they be in learning, say, Haskell or Forth. Not that those are the languages students would be likely to choose, but they are languages that can seem pretty alien (at some point category theorists started exerting a strong influence on Haskell development and now you can't read word one about it without encountering the fearsome Monad, a philosophical term of art turned mathematical term of art turned computer-scientific term of art that's just all over Haskell. Heaven help you if you think its being an English word will go any distance in comprehending what monads in Haskell are or how to use them.)
Thanks for this. Russell and Whitehead do indeed argue that math is a form of propositional logic. Those forumulae could be in English or French or whatever, so yes, "=" means "equals."
As for the specificity of terms--Bill makes this point below--I have trouble with "monad" when it's in Leibniz. Or "differance." But I don't have to know THAT in particular to demonstrate I can translate. Sure some software terms are arcane ENGLISH (or other human language).
Programming is cooking. But a program is a recipe. UC students are now expected to describe a recipe, not cook, to use the metaphor, while others are expected to translate foreign languages.
Bill--software coding is a skill students may need. Why burden the foreign language requirement with it?
Russell and Whitehead somewhat notoriously didn't get very far with that project. Moreover, it just pushes things back a step: why should I think that propositional logic is English (or French) by other means? (Certainly I don't think that "∧" is "and".)
Why should I think that the following is arcane English? I really see no reason to think it is.
module MonadNondet where
import Control.Monad
import Control.Monad.Trans
import Control.Monad.Identity
newtype NondetT m a
= NondetT { foldNondetT :: (forall b. (a -> m b -> m b) -> m b -> m b) }
runNondetT :: (Monad m) => NondetT m a -> m a
runNondetT m = foldNondetT m (\x xs -> return x) (error "No solution found.")
instance (Functor m) => Functor (NondetT m) where
fmap f (NondetT g) = NondetT (\cons nil -> g (cons . f) nil)
instance (Monad m) => Monad (NondetT m) where
return a = NondetT (\cons nil -> cons a nil)
m >>= k = NondetT (\cons nil -> foldNondetT m (\x -> foldNondetT (k x) cons) nil)
instance (Monad m) => MonadPlus (NondetT m) where
mzero = NondetT (\cons nil -> nil)
m1 `mplus` m2 = NondetT (\cons -> foldNondetT m1 cons . foldNondetT m2 cons)
instance MonadTrans NondetT where
lift m = NondetT (\cons nil -> m >>= \a -> cons a nil)
newtype Nondet a = Nondet (NondetT Identity a) deriving (Functor, Monad, MonadPlus)
runNondet (Nondet x) = runIdentity (runNondetT x)
foldNondet :: Nondet a -> (a -> b -> b) -> b -> b
foldNondet (Nondet nd) cons nil =
runIdentity $ foldNondetT nd (\x xs -> return (cons x (runIdentity xs))) (return nil)
option :: (MonadPlus m) => [a] -> m a
option = msum . map return
I don't think even and is "and" either, let alone any other symbol! And I don't have to! Why? Because English as I speak it is not as rigid as software code.
No amount of scary looking stuff that I don't understand touches my argument. I can show you a bunch of recipes for lobster bisque that would pop your mind, dude. They are written in English. I see "map return." I see "option." I see "Nondet" which is presumably an abbreviation, perhaps involving some sense of "determine." And the OED, for which I work, includes some coding senses of words such as “run” that I also see here.
I don't know what "Thou still unravish'd bride of quietness" means. Do you? But I can translate it into French.
Frankly, I don't believe that, if you didn't know what "thou still unravish'd bride of quietness" meant, you could translate it into French. How would you be able to tell if you got it even remotely right? And surely you, a competent speaker of English, know what this phrase, which contains no abstruse vocabulary and is syntactically simple, means.
(Well: you might wonder about "still". Does it mean both "yet" and "unmoving", or just one, or just the other? But to the extent you're uncertain there, you'd have trouble translating it into French (unless there's a word in French that preserves the ambiguity—I don't know French).)
You may not know what it, like, means, man, or what a "bride of quietness" is, but the situation with you and that sentence isn't like the situation with me and (alas, such decay of one's powers) many Latin sentences, where I don't know what they mean because I just can't figure out what goes with what. You couldn't even wonder about "bride of quietness" if you didn't know what it meant.
And, continuing in frankness,I think that there is some amount of scary-looking stuff that does touch your argument. You have maintained, on as far as I can tell solely the grounds that a program written by an English speaker is likely to contain words of, or strings of characters like words of, English, that such a program is in English, in a regimented form, and thus that the description of the functioning of a bit of that program's source is movement from a regimented to an unregimented form of English. I persist in finding this baffling, and part of the reason is that, while actually writing that particular scary-looking stuff above is beyond me, reading it is not (understanding precisely how it works would take more work, translating it into a different programming language, oddly, somewhat less), and brother, it sure doesn't seem to me as if I'm just unregimenting some English. Nor, in implementing an algorithm, does it seem to be a matter of simply regimenting a description independently formulated in less-rigorous English. (Partly because one really does get used to thinking in the language one is using, at least if one is reasonably (these metaphors are practically unavoidable) fluent.) One tends to think of certain classes of problems as, say, folds, where the class is only legible as such because one already has familiarity with the concept of a fold. (Of course the same thing happens when one gains skill in any craft. I don't think we'd be inclined to say that a candidate being quizzed in her knowledge of smithing by having to describe what a smith was doing was just going from a regimented to an unregimented form of English. But perhaps I am wrong and smithing is done in language as well.)
So, if you cannot explain to me in what respect some code—any code!—is just a more rigorous form of English, if you have little familiarity with what coding actually involves, then that does, I think, affect the credibility of your argument. (Imagine a monolingual person who asserted that speaking a second language always involved first formulating inwardly in one's first language the sentence to be spoken in the second, then finding the translation, then speaking it aloud. Someone who spoke two languages fluently might object and say something like, "but look at how easily and fluently I can reel off sentences in this other language!" It wouldn't do for the first person to say, "none of that affects my argument." Our hypothetical monolingual person might even go so far as to say that French is just a regimented form of English, a little odd and hard to get the hang of, to be sure, but there is after all substantial overlap in vocabulary.) (Of course some people really do speak other languages that way, first formulating what they wish to say in their first language and then trying to press that into what they know of the second. The second still isn't, even for them, a form of the first.)
That's right Ben. Propositional logic is neither English nor French. It's not a language. Neither is programming code. It's done IN language, but it ISN'T language, just like the words you're reading here are done IN pixels, but they AREN'T pixels. Dig?
Wasn't your main point that source code is "a form of the same language"? That suggests that it is a language—English, in regimented form, like telegrams or newspaper headlines, except even more formalized. Now you tell me that it's done "IN language", something I'm not sure how to interpret. (The words here aren't done in anything—what does them? They're made up of pixels, but if you tell me that source code is made up of language, I will be even more baffled.)
OK, so add another semester to the program so they can fit in some coding. Or require them to bring it with them from undergraduate school.
It makes sense to have only a reading test for foreign languages, because one can do research in a language without being able to write or speak it, if one can read it. It makes very little sense to have only a reading test for programming languages, since if understanding such things is relevant to your discipline (or to your particular specialty in your discipline), it will be, I assume, because you have cause to write in it. So it doesn't make very much sense to have a reading-only test if you're going to allow programming languages to count.
Quite. But don't put it in the "foreign language requirement" part of the Ph.D. syllabus.
As I more or less said in my first comment, I don't think a programming language should be usable to satisfy a foreign language requirement. (It would be another matter if programs for which it made sense were allowed to substitute a foreign language requirement with a substantively different programming requirement.)
First, I'd like to emphasize what Ben has already said about the reserved words of the a computer language: "...their semantics are independent of their textual representation." The actual functioning of a computer language is no more related to English than to French or Japanese. That the reserved words of the most common computer languages are often English-like reflects the language of their inventors. But really, that's a trivial matter.
Even at that, knowing what those words mean, that is, the functions they 'trigger' in a program, is only the beginning of knowing how to program in a given computer language. It's like chess. You need to know the rules of the game in order to play chess. But you need a lot more than those rules to play even a middling game. So it is with a programming language. It's one thing to know what the commands and constructions mean. It's quite something else to be able to construct useful programs within a language.
You didn't say anything about how students are supposed to establish their knowledge of their chosen language. But writing English language commentary on a chunk of code doesn't strike me as, in itself, a terribly meaningful demonstration. What's meaningful is writing useful programs in the language.
My sense is that the foreign-language requirement was always a practical matter. You learn this or that language so you can read the professional literature written in that language. So, what's the practical value of knowing a computer language? Well, it depends on what the student wants to do. But having some fluency in programming is important in a lot of intellectual specialties, even, these days, some humanities specialties. If, in the context of such an intellectual interest, knowledge of a programming language is a meaningful requirement, then substituting a programming language for a foreign language may well be sensible, subject to the qualification that knowledge of the language is demonstrated in a substantial way.
I don't believe students will be taught to code, which I would support. I believe students will be taught to parse existing code into less rigid forms of English.
I agree with you about the difference between code English and non-code English (or whatever language you choose). Allow me to give an example of code English:
“Baste every thirty minutes until golden brown.”
Now if I've never roasted a chicken I'm not going to know what that means. You can then say “How can you possibily understand the reserved meaning of ‘golden brown’ or ‘baste’ ?” But you would only be criticizing my knowledge of a specialized form of language. And I can easily find out, by reading a book in English that explains these procedures. Finding out about what “basting” means, and executing the algorithm “Baste until golden brown” are not the same as translating one language into another.
"I believe students will be taught to parse existing code into less rigid forms of English. "
If that's the substance of substituting a programming language for a natural language, then there's not much point to it. I have a hard time even imagining such a skill being taught. Are students going to be given chunks of, say, Java code and be asked to 'translate' it into English? What department would offer such a course?
Ben writes: "...[the] semantics [of software code] are independent of their textual representation."
Yes. And so is the semantics of the word “semantics.” Look, it's made of all kinds of squiggles that make my throat and face sound funny when I pronounce them according to certain rules.
Ben is simply describing a default feature of any sign whatsoever.
He's an object-oriented ontologist, he's a coder, he makes amazing games. And he knows about languages, what with having a Ph.D. in Comp. Lit. and all.
This is a necessary debate; I’ve read so much work on the pitfalls of exposing underlying principles between computation language and natural language that I’m unsure of where to start. There does need to be an emphasis on the intrinsic nature of the code in question and some say that the variance of code borders on the bewildering.
The procedural ability of computation is in essence one of increased calculation – and this underscores the language aspect, as many computational aspects rely heavily on different platforms and concepts. It’s important to note that computational language is executable, such that there is a delay between what is written and what is executed (this is a key observation: otherwise bugs and glitches would not occur). For instance, I program in MYSQL which is fairly rigid as open source code goes but is powerful for managing and designing web databases. However with something like HTML and XHTML there is a fair amount of flexibility there in how it can be interepted by a browser - which explains its runaway popularity in the last 16 years.
There is a key difference between code that has been written / studied and code which is executed. Code-in-action is contingent on many factors inherent within a system, but it also has the ability to be contingent on other systems.
There is the aesthetic case for making code sloppy - or by deliberately making it ‘not work’, buts that’s something else entirely.
Tim, your title poses a policy question, but the post itself is more interested in a philosophy of language question that, through the back door, also references your previous post about consciousness.
Clearly the two questions are related. But the philosophy of language question can't entirely determine the policy question, because we make graduate students take foreign language exams for a wide variety of reasons. Because of what we believe about (natural) language -- yes. But also: status, hazing ritual, technical facility (i.e. you will need this in order to get your research done), well entrenched ideas about canonicity, tradition.
Some Ph.D. programs require more languages, some require fewer. Yale English requires a classical language; Berkeley English does not. I've heard of people having trouble getting their non-European languages approved despite obvious relevance to their research. I've heard *cough* that language exams can be administered in a very uneven fashion.
Should a language that's "too close" to English--say, Dutch--count? Should every student be required to pass in a classical language, no matter their field of research? Should "harder" languages count for more somehow? How we answer these questions, as well as the question you pose in your title, depends on what we think Ph.D. students are studying these languages for. But I gather that the policy question isn't your real target.
Let me add a little perspective from the not-so-old old days. I got my degree from SUNY Buffalo back in the mid-to-late 1970s. At the time that was the best experimental program in the nation. And they were hot on interdisciplinary work. So, you could choose between satisfying a foreign language requirement OR presenting Master's level competence in some other discipline. I forget just what the foreign language requirement was (but I'm pretty sure it didn't require a classical language). As for the competence in some other discipline, the department had programs in Lit & Philosophy, Lit & Psychology, and Lit & Society that would allow you to qualify under that option (& maybe it still does, I don't know). Or you could present graduate-level course work in some other department. I choose that option and did cognitive science (through the Linguistics Department).
In the context of a department emphasizing interdisciplinary work, this requirement made sense. You aren't going to get competence in, say, philosophy, by taking one course in, say, the 19th century continental tradition. Some immersion is required, some consistent work over two or more years. The same with any other auxiliary discipline.
Now, if you're studying comp lit you need foreign languages so you can read primary texts in the original language. If you're getting an English PhD as a medievalist, you probably need Latin and perhaps Anglo-Saxon in addition to two or three dialects of Middle English. It would be silly to allow a computer language to substitute for any of those languages.
And if, as Tim indicates, a computer language requirement is to be satisfied by some kind of written exam where you write glosses on code, that's pointless. The issue isn't 'knowing' Java or Python or whatever, but being able to build useful tools with whatever languages you know. And if you're gunning for a philosophical perspective on language and computation, then maybe you need to look at mathematical logic, computational linguistics, or knowledge representation.
Yeah, Natalia, there is a philosophical issue or two here, but these support policy. The two are interrelated. The case *for allowing the "languages" in the English Dept's foreign language requirement are themselves philosophical: the power of precedent has been cited (UCI did it, so should we), the importance of the book Mechanisms that won the MLA prize recently, and that book's call to insist that software code be part of the language requirement options.
Now I happen to think those reasons are unsound, but they are reasons, not just dry policy. Their basis? Some sense that to maintain the status quo is to discriminate against nonhumans.
So in that spirit I offer a rebuttal. It can be boiled down to: yes, let's include code and, better, coding. But not as part of the language requirements. This cheapens both code and the notion of translation.
It turns out UCI don't do it, which is odd, since one argument was that they did. The Culture and Theory requirements include this:
Not quite the same as substituting a software code for a language.