[Humanist] 24.265 getting involved

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Fri Aug 20 23:39:57 CEST 2010


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

  [1]   From:    "Holly C. Shulman" <hcs8n at virginia.edu>                  (120)
        Subject: Re: [Humanist] 24.263 getting involved, but how?

  [2]   From:    James Rovira <jamesrovira at gmail.com>                      (19)
        Subject: Re: [Humanist] 24.263 getting involved, but how?

  [3]   From:    James Smith <jgsmith at tamu.edu>                           (117)
        Subject: Re: [Humanist] 24.263 getting involved, but how?


--[1]------------------------------------------------------------------------
        Date: Thu, 19 Aug 2010 17:27:28 -0400
        From: "Holly C. Shulman" <hcs8n at virginia.edu>
        Subject: Re: [Humanist] 24.263 getting involved, but how?
        In-Reply-To: <20100819203533.9FEF062618 at woodward.joyent.us>


Willard,
I think we might make a distinction between how computer languages work and
the electronic medium as a narrative structure.  To make a comparison other
than that of the automobile, I do not think that the radio producer needed
to understand electro-magnetic transmission in order to understand how radio
needs to be constructed to work.  I suspect for example that the great radio
writers of the mid-20th century period such as Norman Corwin in the United
States and Dylan Thomas in Britain had no idea how the technology of radio
carried their sounds.  But they certainly understood the relationship of the
medium and their message, with its intimacy that could so glorify the sound
of words.  The same could be said for television, cable, and film.

Rather, I think that digital humanity producers need to understand how
information moves in the world of electronic production.  How does this
still-new medium impact writing and narrative structure and visualization
and so forth.  I believe that the future relationship between scholarship
and electronic publication is too important to wait for scholars to become
conversant in XML or TEI.  That said, I do think that scholars need to
understand what XML and TEI, or whatever, do -- how it shapes their
product.  But I do not think they need to be able to do it themselves.

Full disclosure: my father was first a radio and then a television
producer.  He was also one of the least “handy” men I’ve ever known,
preferring always to live in an apartment building with a super than have to
learn how even to change a light bulb.  But his command of how radio and
television reached the ears of listeners, what it meant, and how to do it,
was superb.  I continue to believe that understanding narrative form and
technical expertise are not the same and that in this complex world of ours
we do best to work as teams.

Sincerely,
Holly Cowan Shulman
Founding Director, Documents Compass and Editor, the Dolley Madison Digital
Edition
University of Virginia

On Thu, Aug 19, 2010 at 4:35 PM, Humanist Discussion Group <
willard.mccarty at mccarty.org.uk> wrote:

>                 Humanist Discussion Group, Vol. 24, No. 263.
>         Centre for Computing in the Humanities, King's College London
>                       www.digitalhumanities.org/humanist
>                Submit to: humanist at lists.digitalhumanities.org
>
>
>
>        Date: Fri, 20 Aug 2010 06:34:10 +1000
>        From: Willard McCarty <willard.mccarty at mccarty.org.uk>
>        Subject: getting involved
>
> At one time a number of us spent time arguing that computer-using
> scholars should become computer-programming scholars, and a few of us
> wrote books on programming languages designed to make that easier. The
> thinking was, as I recall, that if only "algorithmic thinking" were to
> become habitual, great strides could be made in humanities computing.
> This argument was related to the ongoing attempt to devise better, more
> humanly expressive programming languages -- better than FORTRAN and
> COBOL, higher-level than C++. Once upon a time I thought that assembler
> language was about as high as one should go, that to twiddle bits was
> not just thrilling but also was to understand what computing was all
> about. But then I never got much done, following yards of printout,
> spread out on the floor, trying to reconstruct the intricate path of a
> flawed micro-algorithmic thought I once had (but had lost) in order to
> find the flaw.
>
> Economics and technological improvements made that sort of indulgence a
> thing of the past, I would suppose, except in very specialised
> applications. But where now do we say that the ideal hybrid scholar's
> mind should be?
>
> In the circumstances I observe many scholars, though persuaded that
> digital methods and tools are Good, have only the vaguest notion of what
> they *are* -- in the way that a painter understands his or her
> paintbrush. I think this is a problem, the sort of one we should be
> trying to solve.
>
> The argument that you don't have to understand the workings of an
> internal combustion engine in order to drive, and all arguments I know
> of that take this form, really don't apply. Computing isn't mechanical
> in the same sense that an internal combustion engine is mechanical, and
> our objectives in using it aren't limited by getting from A to B. We
> want both the "B" and the "getting" to be dynamical, evolving processes.
> But many of our colleagues are still thinking of a simple drive from one
> place they know to another place they know in a vehicle they can trust
> to remain the same.
>
> The solution to the problem seems to be to involve educating the
> imaginations of these colleagues. And it seems to me that the way to do
> this is somehow to involve them in hands-on making of digital things. I
> see far too much standing back and talking about static results
> engineered by someone else, too little engagement, too little scholarly
> craftsmanship.
>
> Comments? Suggestions?
>
> Yours,
> WM
>
> --
> Willard McCarty, Professor of Humanities Computing,
> King's College London, staff.cch.kcl.ac.uk/~wmccarty/<http://staff.cch.kcl.ac.uk/%7Ewmccarty/>
> ;
> Professor, Centre for Cultural Research, University of Western Sydney,
> www.uws.edu.au/centre_for_cultural_research/ccr/people/researchers;
> Editor, Humanist, www.digitalhumanities.org/humanist;
> Editor, Interdisciplinary Science Reviews, www.isr-journal.org.

-- 
Holly C. Shulman
Editor, Dolley Madison Digital Edition
Founding Director, Documents Compass
Research Professor, Department of History
University of Virginia
434-243-8881
hcs8n at virginia.edu



--[2]------------------------------------------------------------------------
        Date: Thu, 19 Aug 2010 18:24:27 -0400
        From: James Rovira <jamesrovira at gmail.com>
        Subject: Re: [Humanist] 24.263 getting involved, but how?
        In-Reply-To: <20100819203533.9FEF062618 at woodward.joyent.us>

Can't speak for anyone else, but if I have to spend time learning
programming on a professional level, it's just not going to happen.  I
have too much other reading to do in my own fields, and no, it's
really not necessary for -me- to know programming for this work to be
done.  Collaboration with people who are already programmers seems a
lot more efficient.  I'm willing to learn programs, but not much
willing to become a programmer.

Jim R



--[3]------------------------------------------------------------------------
        Date: Fri, 20 Aug 2010 12:49:07 -0500
        From: James Smith <jgsmith at tamu.edu>
        Subject: Re: [Humanist] 24.263 getting involved, but how?
        In-Reply-To: <20100819203533.9FEF062618 at woodward.joyent.us>

*** Attachments:
    http://www.digitalhumanities.org/humanist/Attachments/1282326557_2010-08-20_humanist-owner@lists.digitalhumanities.org_5795.2.txt


On 8/19/10 3:35 PM, Humanist Discussion Group wrote:
>                   Humanist Discussion Group, Vol. 24, No. 263.
>
>          Subject: getting involved
>
> At one time a number of us spent time arguing that computer-using
> scholars should become computer-programming scholars, and a few of us
> wrote books on programming languages designed to make that easier. The
> thinking was, as I recall, that if only "algorithmic thinking" were to
> become habitual, great strides could be made in humanities computing.
> This argument was related to the ongoing attempt to devise better, more
> humanly expressive programming languages -- better than FORTRAN and
> COBOL, higher-level than C++. Once upon a time I thought that assembler
> language was about as high as one should go, that to twiddle bits was
> not just thrilling but also was to understand what computing was all
> about. But then I never got much done, following yards of printout,
> spread out on the floor, trying to reconstruct the intricate path of a
> flawed micro-algorithmic thought I once had (but had lost) in order to
> find the flaw.
>    

I suspect much of the techie side of digital humanities still feels this 
way, except that the assembly language of today's web environment is 
PHP, Perl, Python, Ruby, Java, C++, etc.  In years past, I've thought 
that if only our faculty could see the beauty of working in Ruby or 
Perl, then they could become masters of the intricate computational 
machinations that animated their projects.

I've come to believe that the fundamental flaw is not that we expect 
faculty to command computers, but that we expect them to do so in 
languages that have evolved out of Digital Engineering, that field of 
engineering that uses computers to aid their work.

> Economics and technological improvements made that sort of indulgence a
> thing of the past, I would suppose, except in very specialised
> applications. But where now do we say that the ideal hybrid scholar's
> mind should be?
>
> In the circumstances I observe many scholars, though persuaded that
> digital methods and tools are Good, have only the vaguest notion of what
> they *are* -- in the way that a painter understands his or her
> paintbrush. I think this is a problem, the sort of one we should be
> trying to solve.
>
>    
I think part of the problem is that the tools that are flexible enough 
to bend to the needs of the research are so low-level that they are more 
comparable to the molecules that make up the pigments that get mixed 
into the oil to make the paint.  We're having to assemble the molecules 
and don't have time to think about how the paint adheres to the brush.

The tools that are high-level enough that the researcher doesn't have to 
wonder how they work are so high-level that they can't consider the 
nuances in the research.  You can have any color Model T you want as 
long as it's black.  You can have any style concordance you want, as 
long as it's one that was thought up before you downloaded the tool.

We need something in the middle.

> The argument that you don't have to understand the workings of an
> internal combustion engine in order to drive, and all arguments I know
> of that take this form, really don't apply. Computing isn't mechanical
> in the same sense that an internal combustion engine is mechanical, and
> our objectives in using it aren't limited by getting from A to B. We
> want both the "B" and the "getting" to be dynamical, evolving processes.
> But many of our colleagues are still thinking of a simple drive from one
> place they know to another place they know in a vehicle they can trust
> to remain the same.
>
> The solution to the problem seems to be to involve educating the
> imaginations of these colleagues. And it seems to me that the way to do
> this is somehow to involve them in hands-on making of digital things. I
> see far too much standing back and talking about static results
> engineered by someone else, too little engagement, too little scholarly
> craftsmanship.
>    
I couldn't agree more.  I do have some ideas on how to make this happen.

If this had come across this list a few weeks from now, I'd probably 
have some web pages to point to. :-)  Instead, I can point to my own 
development blog: http://dh-dev.tumblr.com/ .

Part of our work has been to build a platform that can support multiple 
projects.  As a single programmer tasked with supporting multiple 
projects, I can't do too much hand-crafted code at the level of Ruby.  
Instead, I've tried to boil each project down to it's unique aspects -- 
the equivalent of an editorial statement -- and create an environment 
that can operate on that 'editorial statement' to produce the desired 
presentation or data transformation.

As a result of this work, I've been able to get the following pieces 
sketched out -- we're still working on tweaking some details:
     * Google Earth display of points mentioned in transcribed texts 
with links to those texts from Google Earth
     * Curated bibliography using the MIT Exhibit tools to create a 
faceted display
     * Curated list of scholars in a field
     * Concordance of transcriptions using MIT Exhibit tools to create a 
faceted display with lines linked to the scans of the original documents 
(eventually to the page in the viewer that contains the line)
     * Paged viewer of manuscripts showing transcription alongside the 
scan of the original document

The list might not seem too long for a year's worth of work, but now any 
one of those items can be replicated fully integrated into the context 
of another project in a matter of hours with all of the work done from 
within the content management system.  The list will only get longer 
over the next year or two.

Part of the goal is to develop a programming language that comes from 
the humanities more than it does engineering.  The nature of computers 
being what it is, there may always be some residual part of the language 
that reminds us of their mathematical side, but I want humanities 
computing processes to be as easy to express as mathematical processes 
are expressed.

There are some things on the horizon that aren't sufficiently settled 
for me to mention them yet, but I think we will be seeing a way forward 
to help scholars feel as comfortable managing the algorithmic side of 
their projects as they are comfortable managing the transcription, 
scanning, or digitization sides.

Of course, all of this could be symptomatic of me falling into the trap 
that you mentioned in the opening paragraph -- if only we had the right 
language, humanists could program!  If I am falling into the trap, then 
hopefully I'm falling in differently than anyone has fallen in before.

-- Jim





More information about the Humanist mailing list