[Humanist] 23.120 programming

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Thu Jul 2 09:26:32 CEST 2009


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

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

  [2]   From:    James Rovira <jamesrovira at gmail.com>                      (69)
        Subject: Re: [Humanist] 23.115 programming

  [3]   From:    robert delius royar <r.royar at morehead-st.edu>             (14)
        Subject: Re: [Humanist] 23.115 programming


--[1]------------------------------------------------------------------------
        Date: Tue, 30 Jun 2009 06:42:23 -0400
        From: David Golumbia <dgolumbia at gmail.com>
        Subject: Re: [Humanist] 23.115 programming
        In-Reply-To: <20090630060715.2BF0423EBE at woodward.joyent.us>


I need to weigh in because, as I suspected, there appears to be a kind of
figure-ground problem in the discussion between Elijah and Jim, one we see
often in these sorts of discussions.

Jim's point was that *code* cannot be ambiguous or fuzzy to work (with some
very minor exceptions around the edges--"standoff markup" and the like,
things rarely used in practice though sometimes dicussed in theory). I will
soften his thesis even more: programming code tends strongly toward
unambiguous structures and statements, because for the most part it must be
interpreted or compiled and then run, and the interpreters and compilers
will not accept *code* that is ambiguous.

Elijah appears to be talking about *software* that can function in/handle
ambiguous input and actions. I do not believe Jim was doubting that this
exists; on the contrary, nearly every software program has "emergent
properties," "strange behaviors" and so on, and most applications must be
able to handle ambiguity of input (to some extent) if it's going to interact
with human beings.

Let me, then, reframe Jim's question: the challenge is to provide a
significant snippet of code, say, a JavaScript function or isolated object
from Java or C++ or so on, in which the operating part of the code is
ambiguous (the compiler could produce multiple correct interpretations) or
fuzzy (the compiler can produce no clearly correct interpretation), but the
software can be compiled and run. Furthermore, because I am interested in
tendencies and not so much in absolutes, the challenge is to proivde
examples of such code that are regularly used in everyday applications.

Personally, I do not know of compilers that can actually handle statments
that are ambiguous at the level of the program--that is exactly one of the
kinds of statements on which a compilers and interpreters are supposed to
choke, and it would also violate the definition of the Turing machine out of
which all computers are built (for which unambiguous *operations* -- not
input -- are required)--but I am eager to learn.

David

      

--[2]------------------------------------------------------------------------
        Date: Tue, 30 Jun 2009 08:43:31 -0400
        From: James Rovira <jamesrovira at gmail.com>
        Subject: Re: [Humanist] 23.115 programming
        In-Reply-To: <20090630060715.2BF0423EBE at woodward.joyent.us>

Thanks much for your response, Elijah.  I would like particularly to
focus upon this paragraph here:

<<I'm not sure how you mean the question, "why would anyone use this
except for personal projects?" though.  What is the "use" of poetry or
literature?  How is a collection of the poetry of Emily Dickinson more
useful than the aforementioned lawnmower manual?  It's drudge work
writing a lawnmower manual, or an academic paper, but we don't claim
that therefore people shouldn't learn to write. If, however, one feels
that the writing of literature is of value and its structures should
be analyzed (And therefore understood to some meaningful extent) then
it would seem the same would apply to creative software and there
would be an incumbent need to be literate enough to analyze and
understand it.  You wouldn't blame a software engineer for not liking
poetry, but you'd likely think him an idiot if he claimed poetry did
not have the ability to pass along complex truths in the way that
software does and therefore that he didn't need to learn how to read.>>

You answered my initial question about "esoteric" uses of coding
through your description of types of lines of code in gaming programs.
 However, I don't completely believe your response, you seem to make
some equivocations without being aware of them, and you seem to be
confusing categories.

First, since we're talking about someone who is primarily a humanist
writing code to present works of art or literature in electronic
formats, I don't think the probably millions of lines of sophisticated
code necessary to make a video game work is quite equivalent.  We're
talking about something much smaller, simpler, and more
straightforward.  XML modifications to video game coding isn't quite
the same either.

Furthermore, being someone who has played these games before, I don't
ever see the code itself.  It's simply not necessary for me to do so.
I only think about the code, in fact, when it fails.  I don't care how
sophisticated, elegant, or esoteric the code itself is.  I do care
than when I toggle right my character moves right and moves right
immediately and consistently.

This is your main point of either confusion or deliberate
equivocation.  When you read poetry, the lines of a poem are
themselves what the reader interacts with.  When you play a video
game, the code itself is almost never what the player interacts with.
In fact, the player should never be aware of the code that creates the
visual appearance of the character and environment.  The only coding
involved by the user should be modifications (which you enter and then
play), or issuing simply written commands that are part of game play.

This is perhaps your silliest comment:

<<You wouldn't blame a software engineer for not liking
poetry, but you'd likely think him an idiot if he claimed poetry did
not have the ability to pass along complex truths in the way that
software does and therefore that he didn't need to learn how to read.>>

Coding itself does not "pass along complex truths," and even if it
did, no one would have access to these truths except programmers.
Coding issues commands -to a machine-, which creates an interface with
a user. Equating "coding" with "software" is a serious confusion of
terms in this case.  Software is the interface, coding is what makes
it work.  The interface itself may look no different from a literary
product: every poem you read on a computer screen is there because of
coding, but it's the poem, not the coding, that communicates complex
truths.

Now you may be calling the coding itself "complex truths" because it
is complex (or can be), but it hardly communicates "truths" of any
meaningful sort.  If our entire world was a vast computer and our
minds a system of computer codes, then yes, I -might- agree with you.
But we don't live in the Matrix and the majority of people who are
alive and have ever lived have no need of computers, much less coding,
yet still manage to communicate meaningful truths to each other.

I believe there could be a phenomenology of coding, in which
programmers write in a "style" that reveals habits of thought, but
again, the coding itself is not designed to do this.  It's just
designed to create a usable interface with a machine, not a person.

I hope you're not confusing those two terms: machines and persons.

Jim R



--[3]------------------------------------------------------------------------
        Date: Tue, 30 Jun 2009 10:15:39 -0400
        From: robert delius royar <r.royar at morehead-st.edu>
        Subject: Re: [Humanist] 23.115 programming
        In-Reply-To: <20090630060715.2BF0423EBE at woodward.joyent.us>

Mon, 29 Jun 2009 00:07:26 -0700 Elijah Meeks wrote

> There are entire
> sections of code in some of these games that never get performed
> except under the most esoteric of circumstances, and there are
> interesting emergent properties of the interacting game world that
> capture the imagination of players and coders, regardless of user
> input.

You might also look at the source (in C) for programs such as Lamda MOO 
and the whole MUD/MOO family.  It provides an interpreter for designing 
interactive spaces and scenarios, so you may also find the language for 
creating objects and actions interesting.

-- 
Dr. Robert Delius Royar <r.royar at morehead-st.edu>
Associate Professor of English, Morehead State University





More information about the Humanist mailing list