[Humanist] 23.139 programming

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Wed Jul 8 07:31:46 CEST 2009


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

[1]   From:    Elijah Meeks <elijahmeeks at gmail.com>                      (31)
Subject: Re: [Humanist] 23.137 programming

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

[3]   From:    John Carlson <carlson at medievalprof.com>                   (23)
Subject: Re: [Humanist] 23.137 programming

[4]   From:    "Mark LeBlanc" <mleblanc at wheatoncollege.edu>              (28)
Subject: Re: [Humanist] 23.137 programming

[5]   From:    Wendell Piez <wapiez at mulberrytech.com>                    (39)
Subject: Re: [Humanist] 23.137 programming

--[1]------------------------------------------------------------------------
Date: Tue, 7 Jul 2009 00:51:50 -0700
From: Elijah Meeks <elijahmeeks at gmail.com>
Subject: Re: [Humanist] 23.137 programming
In-Reply-To: <20090707052503.ACC721B35F at woodward.joyent.us>

David,

I find it rather a poor example to refer to the GOTO command as a sign
of the draconian specificity of code, given that the GOTO command has
been pilloried by the software community for well over a quarter
century exactly because of its draconian specificity (Along with
making unstructured code unreadable).  To take your example into the
modern age, any mediocre programmer could develop a go(Store) function
and object that had any number of different values depending on where
it was called and what the current state of the software.  Quality
programmers could even throw in fancy pathfinding, neural nets and
some multiuser capability to really muddle things up.

This discussion has been littered with archaic bits of software-ese,
with GOTO, COBOL, FORTRAN and computing hardware/software from seventy
years ago.  I'd like to repeat a claim I made earlier on a different
Humanist thread and say that lessons learned from how hardware and
software worked in the 1950s-1970s (And maybe even 80s) have very
little bearing on understanding modern coding and software
functionality.  Issues of processing power, storage, the rise of OO
programming--it all adds up to a difference in kind from the world of
cassette storage and 64k of memory.

For those interested in reading early criticisms of the GOTO command,
which perhaps may have some bearing on our current discussion, you can
take a look at Edsger Dijkstra's "Go To Statement Considered Harmful".
It is very short (Less than 3 pages), focuses on just the subject
we're discussing, and was written in 1968.

Wikipedia has a decent treatment of GOTO, and I'll avoid the obvious
pun in favor of another: humanist.discussion_group($GOTO_Article,
read, respond, make intellectual hay, 0);

I tried to combine as much different programming syntax as possible,
so as to appeal to the broadest audience,

Elijah Meeks

--[2]------------------------------------------------------------------------
Date: Tue, 7 Jul 2009 08:21:15 -0400
From: James Rovira <jamesrovira at gmail.com>
Subject: Re: [Humanist] 23.137 programming
In-Reply-To: <20090707052503.ACC721B35F at woodward.joyent.us>

I also find it odd that computer code would be spoken of as if it
weren't a human language, and said so in a previous post.

Thanks much for this reply, amsler.

> 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.

Again, speaking purely out of personal preference, I always find
coding boring, even when I find the product of coding quite
interesting.  But I've never gone very far with it.

It doesn't amaze or shock me that others can find coding interesting.

Jim R

--[3]------------------------------------------------------------------------
Date: Tue, 7 Jul 2009 10:06:34 -0400
From: John Carlson <carlson at medievalprof.com>
Subject: Re: [Humanist] 23.137 programming
In-Reply-To:
>
  <20090707052503.ACC721B35F at woodward.joyent.us

>
 
"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."

David, Perhaps I'm being dense, but doesn't this illustrate language
functioning as code? You're basically saying that these words act as signs
and/or symbols representing some underlying reality and their meaning needs
to be decoded within specific contexts (i.e., the environmental variables of
an expression). Programming commands also represent an underlying reality
and need to be interpreted in context by some processing entity to make
sense (indeed, you make this point in your story about Grace Hopper). The
underlying reality and processing entity's nature might change, but the
basic activity of translation from an abstract representational system to an
understanding of what those abstractions represent does not - in other
words, there's a formal likeness even if specific functionality and grammars
differ radically.

--John Ivor Carlson
Digital Production Editor
Yale University Press

--[4]------------------------------------------------------------------------
Date: Tue, 07 Jul 2009 11:09:37 -0400
From: "Mark LeBlanc" <mleblanc at wheatoncollege.edu>
Subject: Re: [Humanist] 23.137 programming
In-Reply-To: <20090707052503.ACC721B35F at woodward.joyent.us>

>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.

> 
thanks for this nice comment, refreshing;  i have been cutting code (and
teaching undergraduates from all disciplines to do the same) for over 20
years and i must say my new collaboration mining the anglo-saxon corpus is
some of the most interesting and exciting work i've done
(http://lexomics.wheatoncollege.edu);   no, the code is not earth-shattering
and our analyses are not complex, but writing code to help untangle the web
of relationships in an old corpus brings this programmer to the lab with a
skip in my step;

mark


--[5]------------------------------------------------------------------------Date: Tue, 07 Jul 2009 12:34:23 -0400
From: Wendell Piez <wapiez at mulberrytech.com>
Subject: Re: [Humanist] 23.137 programming
In-Reply-To: <20090707052503.ACC721B35F at woodward.joyent.us>

Hi,

David Golumbia writes:

>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.

Item for debate: an externally specified, descriptive markup language
such as TEI XML is more like "human language" and less like "code"
("programming language"), in the sense David describes.

It becomes more like code (more like Fortran, Basic or XSLT) and less
like human language (English, Latin or Chinese), if it ever does,
only provisionally, when it is embedded in a single particular
processing system -- a particular operational context.

And its refusal to commit to any single such system -- its capacity
to be recontextualized, with its significances adjusted or altered
accordingly -- is intrinsic to its value and usefulness.

Cheers,
Wendell

===========================================================
Wendell Piez                            mailto:wapiez at mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
===========================================================




More information about the Humanist mailing list