[Humanist] 24.359 programming for us

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Fri Sep 24 23:51:47 CEST 2010

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

  [1]   From:    Wendell Piez <wapiez at mulberrytech.com>                   (121)
        Subject: Re: [Humanist] Programming for us

  [2]   From:    Ryan Deschamps <ryan.deschamps at gmail.com>                 (12)
        Subject: Re: [Humanist] Programming for us

        Date: Fri, 24 Sep 2010 10:46:22 -0400
        From: Wendell Piez <wapiez at mulberrytech.com>
        Subject: Re: [Humanist] Programming for us
        In-Reply-To: <1ADC67C5-3442-4558-A619-46A43DFC3D56 at mccarty.org.uk>

Dear Willard,

At 07:41 PM 9/22/2010, you wrote:
>The following questions may seem rather naive. I left programming so 
>long ago that the languages I wrote in are likely to be barely 
>recognizable by name. And the programming practices (those we were 
>taught as canonical) are even less likely to be familiar.

I think your questions are far from naive.

>First, what is it like to work in an environment such as is provided 
>by the iPad or similar device? How does one think about the task in 
>hand as the task-performer conceives it? What does one take for 
>granted? What are the limitations imposed by the system, and how 
>does one get around them or use them to reshape the task?

I assume you mean by this working "on" the iPad, vs. designing or 
programming *for* the iPad. (The iPad SDK, which for the foreseeable 
future will be the only programming environment for iPad, runs on a 
Mac, but not on an iPad.)

And as you know, as far as that goes, the iPad and similar devices 
are offering some innovative new capabilities (as well as some 
interesting limitations) in the physical affordances of their user 
interfaces, which are now making exactly this field of play very 
open. What we will see in months and years to come may be very 
different from what we see now. It is like having a new organ. It is 
having a new instrument.

>Second, how in general does one go about programming these days? Are 
>there more or less standard ways of working? How much of what one 
>can say on this topic would be of benefit if communicated to those 
>who use our tools and do not write programs? Are there good books on 
>"algorithmic thinking" (as a colleague of mine calls it)? How would 
>you like to see the world educated as to what you do?

These are very hard questions to answer because I don't think "one" 
programs these days. I spend long days with my head buried in code, 
and yet to most computer programmers, I am not a programmer, since I 
don't work writing "programs" that do anything like the programs they write.

Programming is a craft or a set of related skills and crafts, and as 
such, it has very fuzzy, and shifting boundaries. Your question is 
somewhat like asking, a century ago (with the advent of power tools), 
"how does one go about woodworking these days". There are answers, 
but there is also change; and there are big differences in what one 
does depending on what one intends to do with what one does (if you 
catch my drift).

Moreover, in my work as a consultant I am regularly faced with the 
conundrum of how people communicate, learn to relate to one another 
and understand what we are up to, in a world that has so far 
outstripped the ability of any individual to understand it, in its 
complexity. I can remember being alerted to this already 25 years 
ago, when I took my car to a tire shop -- bemused by the fact that 
there was a business just for tires, and then getting some slight 
sense, in my dialogue with the tire man in the tire shop, just how 
much there was to know about tires, even while I was impressed by his 
evident interest in them. There was a whole world of knowledge there, 
and this guy had made his home in it.

So personally I think that beyond communicating the specifics of any 
one discipline, it is just as important to expose people to a 
recognition that other disciplines are there, and that they are 
complex (that's why they are disciplines), and not just arbitrarily 
so. This means not just the tools and methodologies, but something of 
the nature of the problems.

I mean, I am not against sharing books or web sites about algorithmic 
thinking or logical problem solving or model building. Far from it. 
But I also want people to know that there is a difference between 
reading a book about algorithmic thinking (maybe solving a few 
puzzles), and being steeped in the problems of real systems design, 
building and maintenance for, oh, say, ten or twenty years. Whatever 
the system. Programming -- especially these days -- isn't just about 
algorithmic thinking. It means becoming familiar with -- going native 
in -- an entire ecology of technical standards, platforms and 
protocols, interchange formats, languages and libraries. (Within this 
ecology, it happens the iPad is something of an island.) I do not 
expect everyone to do this (which would betray the entire purpose). 
But I would like them to get some sense of it without deciding, as so 
often happens, that programmers are alien beings with inaccessible knowledge.

In my experience, the best way to come to grips with this is by a 
familiar example of what not to be. Spend a few years learning about 
something complex. Then talk to someone who imagines himself an 
expert after some shallow or routine exposure to it. (Resolve not to 
be this person.)

Given, instead, an attitude of respect for the knowledge, interests 
and passions of others, one can then begin, maybe, to educate them in 
dialogue about what one does. Don't expect them to move from their 
center; instead try to meet them where they are. From that starting 
point, the normal and natural need we feel to communicate can take over.

>Morgan Tamplin, a colleague at Trent University (Canada), once 
>wisely formulated the key to understanding what our machines are for 
>as learning to see one's object of study "as data" -- or, I like to 
>say, "as if it were only data". The American anthropologist Pascal 
>Boyer speaks of different modes of reasoning, one of them 
>"scientific", the other "erudite" (as in the humanities), best if 
>they cohabit in the same mind. Tamplin's "as data" and the humanist 
>scholar's native mode likewise.

I didn't become a computer programmer because at the crucial moment 
of choice (at age 18) I was shown that the humanistic erudition you 
mention was an important option and counter to the 
seeing-the-world-as-data choice I was also presented with. So I set 
the computer aside for a few critical years. There are things I 
regret about this -- I think I could have been an excellent 
programmer. If I had only learned Unix, and C, and LISP, instead of 
doing whatever it was that I did ... but ... loss and gain.

One thing the humanistic mode teaches, after all, is how much you 
don't know. It may be that nothing human is alien to you -- certainly 
that is an important attitude to cultivate. Yet that outlook is 
completed and energized by the recognition that any of us is lucky if 
we know more than the tiniest fragment of it.

All this is why I think the only strong approach to the problem you 
indicate is in negative capability. By demonstrating a spirit of 
generous inquiry, we encourage others to do the same. Only when they 
are receptive, after all, is there any chance they will be able to 
learn the subtleties of what we want to communicate to them.

And indeed, negative capability -- the assumption that there's more 
to it than one yet knows, indeed than one can know -- is, to my mind, 
the only way to approach programming these days.


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

        Date: Fri, 24 Sep 2010 15:50:16 -0300
        From: Ryan Deschamps <ryan.deschamps at gmail.com>
        Subject: Re: [Humanist] Programming for us
        In-Reply-To: <1ADC67C5-3442-4558-A619-46A43DFC3D56 at mccarty.org.uk>

I have been looking at the scary 'functional' paradigm in computer
programming that is gaining traction in computer programming circles.

Immediately I noticed the advantage of higher-order functions and type-based
access in describing (say) something like poetic meter.    For instance,
creating a recursive / polymorphic type in Haskell:

data Stress a = Up | Down | Iamb  (Stress Down) (Stress Up) | Trochee
(Stress Up) (Stress Down) | etc \ ...

could really help do the heavy lifting for a poetry site.

It's an interesting area to explore (although functional can be a real pain
to learn if you are used to Object-oriented / imperative languages).    It
also brings programming just that much closer to formal logic / math.

Ryan. . .

More information about the Humanist mailing list