This blog has moved

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

I have been a little dissatisfied with the inflexibility of the WordPress unpaid site with regard to customization. I am now using Pelican on Bitbucket, and I look forward to improving my command of CSS and Jinja2 by practicing on the site. I also hope to learn soon how to install Disqus commenting and, since Bitbucket doesn’t support viewing statistics, perhaps trying to set up an analytics service of some kind. Not all of the media has been fully transfered, but I expect to complete that soon. I’m looking forward to composing and editing my posts in Markdown.

Thanks for reading on WordPress up to now.

“Web of Trust” in Chinese and Japanese

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

Thanks for reading on WordPress up to now.


Chinese renders English “web of trust”, in the cryptographic sense, literally as xìnrèn wǎngluò 信任網絡. As a translation it is accurate, but I don’t feel it adds anything to my understanding. It works out to something like “network of one trusting another.”

I find more to think about in the Japanese form, shinyō no wa 信用の輪, which might be translated “wheel (better, loop) of confidence”. Not only is “confidence” a better notion than “one trusting another” for what is being shared in this structure, but I am pleased at the vision of a closed circuit of web-traversal in the word wa 輪.

Taking the larger view of frustrations with technology

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

Thanks for reading on WordPress up to now.


Hack and Tell is having a key-signing party in a couple of days. I’ve never used cryptographic tools and I’d like to learn how they work, beyond just the theory. But I’m frustrated trying to make my way through the jungle of contingencies so as to carry out the basic preparatory work for the party. I dimly remember signing up for a key-signing party in 2012,* and getting so overheated with all the cruft to think about that I finally didn’t attend.

[* New York Linux Users Group announced it for 20120915; the event description was part of http://softwarefreedomday.org/, but the details are no longer on line.]

How to think about this? I know I will get beyond the technical issues before long; the real problem is the moment’s frustration.

I recognize that I am reacting the way my wife does when the computer does not behave as she expects. By temperament she is not much at ease with the layered abstractions the computer imposes on her — the cognitive distance between concrete things she wants to do and the rigidly defined steps the computer requires of her. She has had five such issues today in about ninety minutes:

  1. Pages (her Apple-proprietary word processor) cannot read a file she needs to print. (Because I upgraded her OS and the new version requires a new version of Pages, but it didn’t update automatically or notify us that an update was needed. I realized that an update was needed, then found and installed it for her.)
  2. Some Chinese romanization has begun appearing with a dot under some letters. (Because I upgraded her Chinese utility, and by default the new version places a dot under some vowels whose tonal value can be interpreted ambiguously: cǎiqǔ becomes cạ̌iqǔ because it is phonemically still /cǎiqǔ/ but pronounced /cáiqǔ/. [The single character ạ̌ may not display correctly on all browsers!] I found the correct settings file — not the main one — and turned off this feature for her.)
  3. (Two items.) The new version of Pages has changed the way various things she is used to are displayed. Things she wants (what page am I on right now?) are not displayed the way they used to be, while a drawer is displayed that she doesn’t want (for the “Inspector”, which allows formatting and other high-level adjustments). (I fiddled around with the program and found out how it now works; I showed her how the features she wants are implemented now and how to turn them on and off.)
  4. She wants to format some text but the formatting panel in the Inspector says no object or text is selected. She selects a page but the message doesn’t change, and she hasn’t realized that she is not selecting an “object or text” (I showed her).

In all these cases, I can see past her frustrations without too much stress and solve her problems for her. I usually explain to her what I am doing and why, but the nature of her relationship with computing technology is such that these things don’t always remain long in memory.

What I have to remind myself is that my frustrations with new tools are not of a different kind from hers. That tends to help me muster the resolve to reorient my mind until I can get past the immediate problem.

Reflecting on Bernard Baruch, on the need for character and thinking

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

Thanks for reading on WordPress up to now.


During the late Spring of 2012 I was asked to comment on a remark of Bernard Baruch (1870–1965):

“During my eighty-seven years I have witnessed a whole succession of technological revolutions. But none of them has done away with the need for character in the individual or the ability to think.” Here is what I said:

I agree with Baruch. Certainly no tool is more reliable than the hand that uses it. We witness spectacular miscalculations in the management of sophisticated technology — nuclear plants breached by earthquakes, wars launched for shifting reasons and with immense collateral death tolls, the sudden collapse of economic structures. We ourselves cause these events to become disasters, by putting faith in tools and mechanisms without cultivating sufficient skill and judgment to manage them. Naturally so; tools tend to fail at “edge cases”, and edge cases are often hard to plan for. The situation is just as Baruch says, but I suggest that “character and the ability to think” are themselves actually a kind of technology, to be developed and propagated.

I share Baruch’s pessimism about viewing every new technology in messianic terms; in fact, I think the problems of human existence remain surprisingly alike over time. Granted, our tools for use against those problems have improved enormously, but we remain plagued by basic issues: slavery, hunger, hatred, theft, betrayal of trust, and so on. Consider the suffering caused by preventable diseases. According to the WHO, for instance, easily curable pneumonia and diarrhea still kill well over two million children every year.* No one, however greedy or unfeeling, can think the death of two million children a year from diarrhea is insignificant, and yet somehow humankind does not seem able to prevent it decisively.

Where Baruch’s incisive apothegm does not cut deeply enough is in showing the reach of “character and thinking.” To set against the diarrhea problem we already have effective tools and people with the necessary character and ability to think, but we fail to concentrate our collective will so that the problem actually gets and stays solved. Apparently humankind needs a mechanism for forcing decisive action that we all agree is desirable. The real source of our failure to solve problems like death from diarrhea is narrow self-interest, something deeply seated in human nature. Some of the effects of self-interest are valuable, so learning to control it intelligently is the most crucial domain of character and thinking.

Like Baruch, I want to make change in the world using my gifts. As a professor, I am in a position of power from which to promote a moderate altruism in my students, at least among themselves, through my own example. I try to be generous toward them with my time; I grade in such a way as to encourage responsible collaboration; I try to speak my mind peaceably in case of differences of opinion; I try not to hide the mistakes I make in our subject; and so on. I tell students that, whatever their politics, they belong to the world’s elite by virtue of the education they have received. Above all, I require them to help each other.

I do not know whether doing those things myself really motivates my students to practice the same behavior. But I act on the premise that “character and thinking,” though costly to cultivate and at times a nuisance to use in those edge cases where technology fails us, are humankind’s most powerful tools. As tools, then, they are something not different from “technology” and can be propagated. Displaying their effectiveness through my own example is, I hope, part of a technology revolution whose potential Bernard Baruch would not dismiss.


*. World Health Organization, “Causes of child mortality for the year 2010.” 
http://www.who.int/gho/child_health/mortality/mortality_causes_text/en/index.html, accessed 29 May, 2012.

Dinner with a Bletchley Park cryptographer

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

Thanks for reading on WordPress up to now.


Michael Loewe, the eminent Cambridge historian of China, came to speak at the Institute for Advanced Study and at Princeton University on 19–20 November of this year. A few of the sinologists from the School of Historical Studies at the IAS dined with him after his first talk. I had not realized that Loewe had once been at Bletchley Park and that his initiation into the languages of East Asia came in a rudimentary course in Japanese, hurriedly thrown together for Bletchley workers in the weeks after Pearl Harbor. It began in February, 1942.

Living as I now do in the oddly-configured space between sinology and computer science, the conversation was a particular delight for me. Bletchley Park is one of the landmarks in the evolution of computer science before the invention of the transistor. And while I am not prone to the worship of people or things, it was a pleasure to have the company of this hale 91-year old scholar for an evening and hear him reminisce in his own voice about cryptography seventy years ago.

Loewe told us a number of stories of Bletchley, and I won’t repeat them here as I see they are essentially all documented in his seven-page paper “Japanese Naval Codes” in the Hinsley and Stripp Codebreakers book.[1] I had not read this book before, and would like to recommend it here. It is thickly stocked with personal memoirs of the Bletchley Park work by thirty different participants, and should satisfy any reader’s hunger for historical and technical detail.

While Bletchley is most famous for the reconstruction-at-a-distance of the settings of the Enigma machine, associated in memory with the stellar name of Alan Turing, I was more impressed by the descriptions of the collaborative nature of all the cryptographic work and of the study of Tunny and Sturgeon — code names for the two other German cryptographic machines. And still more striking was to realize how much of the work at Bletchley was of no Computer-Science interest at all. It was exceedingly dreary clerical labor, performed manually at all hours of the day, because the vast majority of Axis cryptographic tools consisted of simple ciphers and codes, applied by hand to plaintext and then decoded by hand. If there is any Computer-Science lesson in all this drudgery, it is only that automation initially enabled ciphers to resist decryption more robustly and to introduce greater variability-with-reproducibility to the encryption process; that robustness and reproducibility are what drove Turing and the others to their mathematical advances. As for Japanese, Loewe and the other Bletchley writers make clear how minor a subject it was in English wartime cryptography. All the work they did on it was clerical in nature and very low-level.


I was charmed by Loewe’s accent. I transcribed a few distinctive expressions:

  • [mai-θə-ˈlɒ-dʒɪ-kl̩]: mythological
  • [ˈju-njukʰ]: eunuch
  • [ˈɛm-pʰɹʌ]: emperor
  • [ˈlai-bɹiː]: library
  • full trust of his loyalty: I would use “in” rather than “of” here.
  • a forward protagonist

The first two of these were completely new to me and surprising. He also pronounced the second half of Milton Keynes, the major town near Bletchley Park (now the borough containing it), as [kʰeinz]. He gave the name of the course of study in (Western) Classics that he had been enrolled in at Cambridge before Bletchley as “Classical Mods” — short for Classical Moderations, a name that remains in use today. The expression “moderations” apparently has to do with the fact that this curriculum features examination by disputation, conducted by faculty “moderators”. Good training for sinology and cryptography, even if of the dreary clerical variety.

Loewe’s surname is pronounced ['lou-wiː].


Notes

[1] F. H. Hinsley and Alan Stripp, eds., Codebreakers (Oxford: Oxford University Press, [1993] 1994 [paperback]), pp. 257–63. This is quite a different work from David Kahn’s Codebreakers, a more general history of cryptography.

Karl Popper on conflict between your basic assumptions and those of your interlocutor (1965)

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

Thanks for reading on WordPress up to now.


Karl Popper:

The myth of the framework can be stated in one sentence, as follows.

A rational and fruitful discussion is impossible unless the participants share a common framework of basic assumptions or, at least, unless they have agreed on such a framework for the purpose of discussion.

In the formulation I gave of the myth, it is a fruitful discussion which is declared impossible. Against this I shall defend the directly opposite thesis: that a discussion between people who share many views is unlikely to be fruitful, even though it may be pleasant; while a discussion between vastly different frameworks can be extremely fruitful, even though it may sometimes be extremely difficult, and perhaps not quite so pleasant (though we may learn to enjoy it).

— “The Myth of the Framework” (1965, 1974), in M. A. Notturno, ed., The Myth of the Framework: In defence of science and rationality (London and New York: Routledge, 1994), pp. 33-65; quotation from pp. 34-5.

My Hacker School Pairing Interview

I have moved my blog from WordPress to a static site — currently http://dpb.bitbucket.org/. Atom feed is available at https://dpb.bitbucket.org/feeds/all.atom.xml.

Thanks for reading on WordPress up to now.


Hacker School admitted me to its Winter 2013 batch last January. I don’t think I’ve written here about my experience on the interviews yet, and I’ll do so now. There was so much to say about the second of them that I failed to compose either a diary entry or any letters to friends containing much of value. So what follows is reconstructed from later notes and my memory.


When I was admitted, the practice was to conduct two interviews. The first was a general conversation begetting I suppose a sense of my personal (not professional) goals in applying to Hacker School and how my personality would mesh with the rest of the ecosystem of the place. The second one, which had to be done with a different person, involved pairing on some piece of code that I had already written — adding a small feature or refactoring.

At core, both of these are evaluations of personality. So I can’t offer any advice beyond: be your own true self, and in the pairing interview share your actual thinking about the details of your code. Hacker School is a very effective environment for someone who reflects critically about how his code works and reacts without prickliness to other people’s suggestions.

For the pairing interview I submitted a Python progress-bar class that I remembered worked when I stopped work on it half a year before. Thirty minutes before the interview I tried it out, found it was broken, and went into high hysterics trying to figure out what was wrong. That proved to be much better preparation for the interview than all the placid reading of the code that I had done earlier. I fixed the last of the bugs a minute or so before the interview started, and was in a good state of mind to talk confidently about details.

The interviewer asked me to walk her through the code, and as I did I pointed out places where there I thought I could improve functionality. I started out on a fairly high level, but the interviewer wanted to know about details of implementation. My little class relied on the multiprocessing module to run the progress bar independently of the task whose progress was being tracked and continually received information from the task as ctypes values, and we talked a bit about that. At the very end she asked me how the use of multiprocessing affected running time, something I had not yet learned how to measure and consider. (I started doing so immediately after the interview; the answer is that running time is affected to a disastrous degree, a cost of something like a thirteen-fold slowdown. The project now lives in a directory named abandoned_but_do_not_discard.)

She also commented on my style of naming imported modules, for instance:

import struct
import sys
import os
import time as T
import random as R
import multiprocessing as M
import ctypes as C

Any module with a long name or that I refer to often I name with one or at most two capital letters. That saves typing and makes it easy to see quickly and unambiguously when a module is in use. The interviewer remarked that she hadn’t seen that done before and wondered where I learned it. I no longer recall where I learned it or whether it was my own shortcut. When I joined the batch I was told it wasn’t part of best practice and I stopped using it, but I’ve started again recently; I think it’s effective and clear to anyone reading the code with sufficient care.

My feeling was that the interview went well. But when I heard back from Hacker School at the end of the day I observed that I felt surprised that I had been admitted.


I can’t recommend Hacker School enough for someone in a situation like mine. At the institution’s request for a testimonial recently I described that situation and Hacker School’s effect as follows:

I came to programming after a decades-long career in a totally unrelated and non-quantitative field. After exposure to a couple of programming languages, and after taking some math and theory courses, I was still a very green peach. Hacker School ripened me into the ways of the guild of coders: I learned how to read other people’s code, to pair-program, to ask for help in a way that was useful to myself and others; I got used to jargon, along with how and when to use it; I learned various best practices and the names of many, many tools. Above all else, I learned to think of myself as a coder, really and truly, and I find myself now part of a growing family of pleasant, helpful brother- and sister-coders.

There are things I would like to say about what I see as the long-term effects of the presence of this group of “pleasant, helpful brother- and sister-coders” in the field. But I will save that for another day.