[Humanist] 23.569 finding software, or perhaps not

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Fri Jan 15 09:40:25 CET 2010


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

  [1]   From:    Alan Corre <corre at uwm.edu>                                (29)
        Subject: Humanist Discussion Group, Vol. 23, No. 566

  [2]   From:    Jockers Matthew <mjockers at stanford.edu>                   (78)
        Subject: Re: [Humanist] 23.566 finding software, or perhaps not

  [3]   From:    Amanda Gailey <amanda.gailey at gmail.com>                   (42)
        Subject: Re: [Humanist] 23.566 finding software, or perhaps not

  [4]   From:    Martin Mueller <martinmueller at northwestern.edu>           (46)
        Subject: Re: [Humanist] 23.566 finding software, or perhaps not


--[1]------------------------------------------------------------------------
        Date: Thu, 14 Jan 2010 04:04:05 -0600
        From: Alan Corre <corre at uwm.edu>
        Subject: Humanist Discussion Group, Vol. 23, No. 566

In response to the comment of Richard Lewis: "The things that make 
computational scholarship interesting can't, I think, be packaged up in 
an end user application…" I should like to quote from the preface to my 
book *Icon Programming for Humanists* (1990):

"The Icon programming language is a good choice for those whose main 
interest is the written word. It is structured so that it emphasizes 
proper programming principles, yet it does not carry the philosophy of 
structuring to the lengths of Pascal. It strikes a reasonable balance 
between structure and freedom, between being a disciplinarian like 
Pascal and an easygoing but perhaps overindulgent friend like SNOBOL-4, 
the unstructured ancestor of Icon. It has excellent facilities for 
handling strings of characters, which is the essence of this type of 
programming; flexible structures such as lists, tables, and sets; and 
useful built-in sort capabilities…All these features add up to making 
Icon the language of choice for humanistic programming."

I have prepared an updated second edition of this book, including two 
entirely new chapters on employing Unicode and on the Text Encoding 
Initiative. New programs include examples in Russian, Tamil, and Hebrew 
to demonstrate its usefulness for non-Roman script languages. The 
manuscript has passed between me and the editor, Clinton Jeffery, 
Professor of Computer Science at the University of Idaho, several times, 
and the final redaction is now in his hands. It will initially appear as 
an e-book, and the price will be right, namely $0.00. You can get a peek 
at the cover at https://pantherfile.uwm.edu/corre/public/Humanist_Cover.jpg

God willing, before the end of the year, you should be able to look inside.

Alan D. Corre
Emeritus Professor of Hebrew Studies
University of Wisconsin-Milwaukee
USA



--[2]------------------------------------------------------------------------
        Date: Thu, 14 Jan 2010 05:50:28 -0800
        From: Jockers Matthew <mjockers at stanford.edu>
        Subject: Re: [Humanist] 23.566 finding software, or perhaps not
        In-Reply-To: <20100114061256.5D62F46714 at woodward.joyent.us>

Richard makes a number of very good points here.  I wonder if our "tool-building" efforts have been a bit misdirected in favor of GUIs and web-based applications.  We might learn from the NLP-oriented linguists, statisticians, and others (including even the Drupal community) who have moved in the direction of open-source solutions and user-contributed modules.  Two such "tools" that I use daily include R (the stats package) and NLTK (the Python-based Natural Language Toolkit).   Both R and NLTK are just programming languages for which a number of methods/functions/tools/packages have been developed to address the sorts of challenges those communities encounter.  Many (perhaps most) of these methods/functions/tools/packages were developed not because some programmer thought to himself, "hmm, I bet the folks could use a ____ tool."  But rather because some researcher needed to overcome a particular challenge in order to complete some research goal.  Some modules in R and NLTK and other such "apps" are hardly ever used, others are bread and butter. Though I do send newbies to the wonderfully easy to understand projects such as Tapor, I find I require a more malleable workbench.
Thoughts?      
--
Matthew Jockers
Stanford University
http://www.stanford.edu/~mjockers



--[3]------------------------------------------------------------------------
        Date: Thu, 14 Jan 2010 10:19:36 -0600
        From: Amanda Gailey <amanda.gailey at gmail.com>
        Subject: Re: [Humanist] 23.566 finding software, or perhaps not
        In-Reply-To: <20100114061256.5D62F46714 at woodward.joyent.us>

Richard,

I find your thoughts on this intriguing, and you articulate something
that has given me pause about tool-building.  Largely--with
exceptions, of course--tool-building seems to benefit the builder more
than the imagined end-users, who don't engage the materials as the
builder did and don't have the cognitive benefit of working through
the problem-solving process.  (I think the same is true of text
encoding.)  In some ways these perhaps are not *tools* at
all--repurposable implements like hammers--but performances, which
other people can mimic in their own contexts but without the
freshness, authenticity, excitement, or risk of the original.  If all
this is true, I don't know that it should diminish the place of
tool-building within digital humanities, but ask us to think about it
as a different kind of activity than how it is often cast.

Amanda

> It may also be the case that people don't really want tools at
> all. And that most tools that have been provided aren't up to the
> job. (Of course, someone will find an exception to this sweeping
> generalisation in a tool for their home discipline.)
>
> But I'm increasingly of the opinion that end user application style
> software is not really what scholars who are serious about exploring
> the possibilities of using technology to enhance their research or
> open new avenues of research require. Rather, I'm beginning to feel
> that a good grounding in programming, a simple, expressive language,
> and good provision of libraries for abstracting over data encodings
> and difficult algorithms required in each discipline will be much more
> conducive to interesting computational scholarship.
>
> The things that make computational scholarship interesting can't, I
> think, be packaged up in an end user application. Like scholarship
> conducted in any paradigm, computational scholarship is interesting
> and worthwhile when it's exploratory. But the restrictions of an end
> user application seriously stiffle any possibility for exploration.

-- 
Amanda Gailey
Assistant Professor
Department of English
Center for Digital Research in the Humanities
University of Nebraska
202 Andrews Hall
Lincoln, NE 68588



--[4]------------------------------------------------------------------------
        Date: Thu, 14 Jan 2010 10:53:21 -0600
        From: Martin Mueller <martinmueller at northwestern.edu>
        Subject: Re: [Humanist] 23.566 finding software, or perhaps not
        In-Reply-To: <20100114061256.5D62F46714 at woodward.joyent.us>

> 
> 
> But I'm increasingly of the opinion that end user application style
> software is not really what scholars who are serious about exploring
> the possibilities of using technology to enhance their research or
> open new avenues of research require. Rather, I'm beginning to feel
> that a good grounding in programming, a simple, expressive language,
> and good provision of libraries for abstracting over data encodings
> and difficult algorithms required in each discipline will be much more
> conducive to interesting computational scholarship.
> 
> The things that make computational scholarship interesting can't, I
> think, be packaged up in an end user application. Like scholarship
> conducted in any paradigm, computational scholarship is interesting
> and worthwhile when it's exploratory. But the restrictions of an end
> user application seriously stiffle any possibility for exploration.
> -- 

Richard Lewis' comment raises a central problem, even though his conclusion may be a little too pessimistic. I have from time to time warned about the Devil User-Friendly.  It takes a little while to learn how to ride a bicycle, not to speak of learning how to play the violin. But people think that you should be able to perform all manner of complex computational operation by just pushing a button, or at most two. 

This is possible if the complex operations serve goals that have been previously and narrowly defined. But that is not what happens in research, where you constantly adjust your goals and methods as you go along.  However gifted you are as an interface designer, you will never be able to anticipate all the things that users will want to do. Applications designed for business or entertainment can hone in on the half dozen most popular or useful operations and perfect them. But that is not  a plausible model for research. 

On the other hand, Richard Lewis may state the opposition in somewhat too stark terms. In Ellen Ullman's splendid book 'Closer to Machine' there is a page where she contrasts Microsoft Word as a program that makes users stupid with Microsoft Excel as a program that encourages ingenious data exploration. You don't need to be a programmer to do interesting things with Excel, but you do need to think about your data, and more is involved than pushing buttons. 

There is not much software in the Humanities that operates at an Excel level.  There is also very little work on maintaining and delivering data in formats that support post-processing and encourage users to pick up data manipulation skills that can be learned in days or fewer weeks than can be counted on the fingers of one hand. As a result, we live in an either-or world. 

On the one hand, there are the hackers, often with experience that stretches back into their teens and skill levels that are virtually impossible to replicate once you're twenty. Somewhere in this world there may be a person who started playing the piano at 20 and played the Appassionata at speed at 23. But there aren't too many of them. And it may be the same with programming skills. 

On the other hand, there are the users and the interface designers who believe that humanities computing operations must follow a 'thirty-second model': if it takes more than 30 seconds to formulate the commands for an operation or wait for its results, FORGET IT. Not much good will come from such an approach. 

Somewhere between these extremes is an 80/20 solution where you start from more realistic, i.e. higher expectations of what users need to bring to the table but also do your best to lower the time and expertise cost of working with digital data. I remember reading in some manual of the R language that performing a statistical operation is often simpler than wrangling the data into shape.  But R the last time I looked at it didn't have a built-in or black box routine for importing Excel data -- a small but striking example of an unnecessary obstacle. 

So I agree with Richard Lewis that "the things that make computational scholarship interesting can't, I think, be packaged up in an end user application." But there are still a lot of things that can be done to lower the entry barriers for scholarly and exploratory analysis of primary humanities data in digital form. 







More information about the Humanist mailing list