[Humanist] 23.137 programming

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Tue Jul 7 07:25:03 CEST 2009

Humanist Discussion Group, Vol. 23, No. 137.
Centre for Computing in the Humanities, King's College London
Submit to: humanist at lists.digitalhumanities.org

[1]   From:    David Golumbia <dgolumbia at gmail.com>                      (64)
Subject: Re: [Humanist] 23.134 programming

[2]   From:    John Carlson <carlson at medievalprof.com>                   (38)
Subject: Re: [Humanist] 23.134 programming

[3]   From:    amsler at cs.utexas.edu                                      (23)
Subject: Re: [Humanist] 23.134 programming

Date: Mon, 6 Jul 2009 06:20:38 -0400
From: David Golumbia <dgolumbia at gmail.com>
Subject: Re: [Humanist] 23.134 programming
In-Reply-To: <20090706090322.09F271FD95 at woodward.joyent.us>

Jim wrote:

I could simply rephrase my statement to say that we do not think in one type
> of code (computer
> code) but do think in another type of code (human language).  This is
> a response you may have anticipated.
> I tend to think in terms of a distinction between mathematics and
> verbal languages, and see computer code as a hybrid that largely
> follows math conventions.

To build on what Jim says, because this happens to be a particular interest
of mine, and while I won't go into great detail here, the entire idea that
the mind or language functions via a "code" that is anything like a logical
or mathematical language is just false (which is not to say that *some
parts* of mind and language have code-like operations; of course they do. We
can talk and think about math. We can talk in and think about logical
notation, etc.). Cognitive scientists and linguists have been trying for
more than 50 years to find such codes and they have failed, period, and
there is broad scientific and especially linguistic consensus that this is a
failed idea. I talk about this at some length in the 2-4th chapters of my
book,* The Cultural Logic of Computation* (Harvard UP, 2009), and just
because the issue keeps coming up, I have some more pointed work in progress
addressing the history and cultural contexts of the view.

And where did the view come from? Until the 1950s, programming languages
were called "codes" and almost nobody (other than some hard-core
computationalists) thought they were like human languages. The concern was
that everyone but mathematicians were afraid of programming. At a conference
at MIT in the 1950s Grace Hopper and others suggested replacing mathematical
concepts with English words in some new higher-level languages (you know
their names) and calling them "programming languages" so that fewer people
would be afraid to use them (see earlier conversation). That didn't make
them languages, and nobody in those rooms was looking into the
characteristics of human languages in depth to make the comparison (and
there were no linguists there). So to say as someone earlier did, and as
many people do, "they are called languages and so they are languages" is to
give an awful lot of power to a small group of people who were not, in fact,
thinking about the question at all. Yet one hears it repeated over and over
again, which really shows the power and function of human language and
ideology to structure social relations.

There are so many reasons the human languages and programming languages are
not alike. I will give only a single philosophical argument, which i find
especially convincing, although ymmv.

Human languages can only be "interpreted" in context, and even then univocal
interpretation is the exception, while the rule is ambiguity. That is,
almost every utterance appears to be functioning at both more than one level
and also at no particularly concrete "level." Do the exchanges in "small
talk" in fact mean what they appear to refer to? A strong argument can be
constructed that they "mean" things about the social relations between the
talkers, and very little about the ostensive speech topics.

Programming langauges can only be interpreted via the single direct
reference of their terms, which cannot by definition, in that role, be
interpreted ambiguously.

English sentence, out of context: "go to the store."  you may think you know
its 'meaning,' but there is no "fact of the matter" about it, and without
inserting it into context, you have no idea about its "real" function or
meaning. I could place the sentence into a hundred different contexts that
would radically change its function and import.

Basic sentence: "Goto 14." One "interpretation": go to line 14. human beings
can make other things out of it (making it function as human language), but
in its role as a line of program, it has a single, unambiguous, univocal
"interpretation" that is more like a Fregean "reference" than a "meaning."
If the program fails to go to line 14 on reading this statement, it is in
trouble. This is absolutely true regardless of the context of the sentence.


Date: Mon, 6 Jul 2009 09:21:02 -0400
From: John Carlson <carlson at medievalprof.com>
Subject: Re: [Humanist] 23.134 programming
In-Reply-To: <20090706090322.09F271FD95 at woodward.joyent.us>

"I could simply rephrase my statement to say that we do not think in one
type of code (computer code) but do think in another type of code (human
language).  This is a response you may have anticipated."
Indeed - the second part of my response depends on the tensions exposed or
created when moving between different types of code. I do object to the
assumption, though, that some things should only be expressed in one type of
code/language (very different from more useful observations about whether
some things are easier to express in a particular code/language).

Every mode of expression, or code, is flawed/limited in some manner -
indeed, the quality of "indeterminacy" that provides the richness of meaning
to poetic expression could be thought of as a flaw (assuming the transfer of
information to be the primary purpose of communication). However, like many
apparent limitations in code, this flaw has been turned into a feature over
time. The very characteristics you see as limiting programmatic code should
also be thought of as flaws with the potential to become features.

Finally, I would add that it seems a bit odd to claim that computer code is
distinct from "human language" - we're still the ones doing the talking,
after all, even if the grammar seems foreign to you. Perhaps, though, my
perspective is different because my primary interaction with programmatic
code has been through markup languages like TEI XML. Such coding systems
carry greater semantic weight than "hard" (true?) programming languages and
could perhaps be seen as occupying an intermediary space between strictly
linguistic and strictly programmatic code. However, if you can have a
programmatic language with strong linguistic tendencies (or vice versa) that
would also seem to imply that the hard distinctions you try to draw between
different types of code are imaginary.

Date: Mon, 06 Jul 2009 12:42:52 -0500
From: amsler at cs.utexas.edu
Subject: Re: [Humanist] 23.134 programming

I think the discussion of the difference between computer code and human
language has gone off the tracks. The fundamental difference between
computer code and human language is that computer code is meant to cause a
machine to do something. The closest analogy in human language terms would
be the commands of military leaders to their troops.

The reason programming is appealing is that you get a chance to absolutely
control the actions of a machine. Unlike in the case of human language,
where under normal circumstances you can at best hope to sway judgement or
influence opinion, in programming the code directly changes the behavior of
the computer. Even in the analogy with military orders, you can't be certain
that the orders will be carried out exactly as you intended.

To describe this type of activity as 'boring' probably has more to do with
the goals the programmer has for the code than the actual creation of the
code. If you're programming a boring task, then the code may well be a
boring thing to write. However, if the task you're programming the computer
to perform involves arriving at a new display of information that can reveal
hidden properties of data, especially text data, and the techniques being
imployed are not certain to work (you can only see so far ahead, much as in
a game of chess), then I would find it hard to describe the task of writing
such code boring.

More information about the Humanist mailing list