Humanist Discussion Group, Vol. 17, No. 279.
Centre for Computing in the Humanities, King's College London
www.kcl.ac.uk/humanities/cch/humanist/
www.princeton.edu/humanist/
Submit to: humanist@princeton.edu
[1] From: Stéfan Sinclair (45)
<Stefan.Sinclair@ualberta.ca> (by
Subject: Re: 17.271 dance steps to coding
[2] From: Willard McCarty <willard.mccarty@kcl.ac.uk> (53)
Subject: dance steps
--[1]------------------------------------------------------------------
Date: Sat, 04 Oct 2003 06:37:54 +0100
From: Stéfan Sinclair <Stefan.Sinclair@ualberta.ca> (by
Subject: Re: 17.271 dance steps to coding
Dear Colleagues,
Like Stephen Ramsay, I derive enormous pleasure from programming: it is a
truly creative outlet for me. I find it thrilling to make something that
may never have been made before, because either the functionality or the
algorithm is unique (I'm not necessarily talking about sophisticated
algorithms, the combinatorics of programming - many ways to do many things
- quickly leads to an impression of originality, even for the simplest tasks).
I am also an auto-didact, which certainly does present some opportunities
and challenges. I often think that my lack of formal training allows me to
imagine novel ways of confronting a problem, as I may be oblivious to the
"right" or "usual" way of doing it. On the other hand, there's good reason
why some conventions and practices are taught formally: one can waste a lot
of time and effort (and the time and efforts of others subsequently), by
doing things poorly. Mostly, I feel a constant sense of modesty about my
code, especially when it's put before trained programmers. No matter how
smug I feel about the functionality of the program (what it does for the
end-user), I can't help but feel self-conscious about the actual code.
I regret the fact that I seem to have less and less time to learn new
techniques and languages. As a student I could almost always make time for
these activities - or burrow into the night - but continuous days of
programming are a rare luxury now. I know of some colleagues who are only
able to reserve such blocks of time during sabbatical years. Moreover, as
some of us discussed at ACH/ALLC 2003 in Athens, there's currently very
little professional incentive for me to do coding rather than, say, work on
a scholarly article. I think that by creating mechanisms of peer-review for
software development (including the evaluation of code, documentation,
functionality, etc.), we would encourage more people to develop much-needed
tools for our community. (Sorry, I digress.)
I think that the integration of programming into our humanities computing
(or whatever we prefer to call it) curricula is essential. By teaching
students to create their own tools, instead of relying exclusively on
what's available, we're empowering students to imagine entirely different
ways of doing things. This may not be of interest to all students, but I
think all of them are likely to benefit from some familiarity with the
possibilities and limitations of programming code.
Then again, teaching our students to code may rob them of some of the
pleasure that auto-didacts feel in creating so many of their own approaches
and techniques. Or maybe there's a way for us in Humanities Computing to
balance rigour where needed and flexibility where desirable...
Stéfan (Stéfan)
--Stéfan Sinclair, University of Alberta Phone: (780) 492-6768, FAX: (780) 492-9106, Office: Arts 218-B Address: Arts 200, MLCS, UofA, Edmonton, AB (Canada) T6G 2E6 M.A. in Humanities Computing: http://huco.ualberta.ca/
--[2]------------------------------------------------------------------ Date: Sat, 04 Oct 2003 06:49:17 +0100 From: Willard McCarty <willard.mccarty@kcl.ac.uk> Subject: dance steps
Permit me some cane-thumping (rather than dance-stepping) on the subject of learning how to code. Permit me a bit, then some more youthful observations. Leaps of enthusiasm.
My involvements with computers go back to sights of drum memory (accompanied by stories from those who had written code in which calculation of the speed of rotation of the drum and so time-to-next-instruction played a role); plug-board programming for some devices; vacuum-tube/valve computers that occupied large, intensively air-conditioned rooms; punched cards; reels of magnetic tape mounted on drives taller than I was -- you get the idea. I learned programming before there was computer science from a wizard named (I kid you not) Bill Gates, a PhD candidate in physics who had found computers more interesting than subatomic particles. Among programmers, especially systems programmers of the time, he was famous. He taught me Fortran for the CDC 6600 (at the Lawrence Radiation Laboratory, Berkeley) and how to use a handy hardware-location statement special to that version to reach out of allocated memory and take over protected functions of the machine, in one or more of the 13 "peripheral processors". Every time the machine crashed we would get a call.... And he taught me assembly language for the CDC. It was love at first shift-left-accumulator. It was programming as craftsmanship of the kind, I suppose (but correct me if I am wrong), rarely encountered these days. Those who wrote code for the Commodore 64 and its ilk will know what I mean: how to use every last memory location, sometimes for more than one purpose simultaneously. There was a contest for some time at the Rad Lab, in the Alvarez Group: who could get an absolutely crucial, very often called routine in the OS program loader condensed down into 8 64-bit instructions so the entire thing would fit into the hardware "stack", therefore not have to be repeatedly itself loaded, therefore cause the entire OS to run much, much faster. I didn't win, but I remember the celebration for the programmer who did.
Apart from entertaining memories and semi-impressive cane-thumping, the value of all that for me was a lesson I learned repeatedly in other media, such as wood (furniture-building) and ink (calligraphy) -- the disciplinary value of craftsmanship, of disciplined thinking, and something else equally as important: direct, practical confrontation with computational tractability, its implications and consequences. That last thing is absolutely central to an understanding of what we in humanities computing do.
So, the problem that Chairman Mao faced: how do we instill in the upcoming generation the deep values acquired on the Long March? Not by his means.... But if we can impart that sense of craftsmanship, of skill not as something we try to bury because it is socially unacceptable in academia -- the lace cuffs and long, long-handled brush so as not to get paint on the fancy clothes -- but as a genuine badge of honour, then we will have done something really important for our students and colleagues. Skill should not be buried under a load of philosophy or some other concealment but illuminated by means of philosophy. But you have to have the skill first, the actual disciplined experience.
Comments?
Yours, WM
Dr Willard McCarty | Senior Lecturer | Centre for Computing in the Humanities | King's College London | Strand | London WC2R 2LS || +44 (0)20 7848-2784 fax: -2980 || willard.mccarty@kcl.ac.uk www.kcl.ac.uk/humanities/cch/wlm/
This archive was generated by hypermail 2b30 : Sat Oct 04 2003 - 01:58:14 EDT