Friday, September 21, 2012

"A Kind of Kafka Steeped in LSD and Rage"


(title stolen from Roberto Bolaño)

So there is a Philip K. Dick festival this weekend. I think I will be going, although not sure precisely why. I am a fan, but not a fan of fandom. But this has too many interesting speakers to ignore. PKD is more than a pulp SF writer – a visionary, spiritual seeker, philosopher, prophet. I get the sense he would be amused by those labels, and perhaps refuse them.

I was first exposed to PKD in my youth, when I stumbled on a copy of Ubik at the library. At the time it seriously freaked me out, and possibly I never completely recovered from that. Ubik is a story of the usual Dickian mid-level corporate functionaries who get caught up by the machinations of implacable and hostile forces, and end up having reality itself crumble around them.

Back then, science fiction (like computer hacking) was a tiny and reviled subculture. Since then both have not only become mainstream, but culturally dominant. PKD's work of course has been mined for movie scripts ever since his death, with middling results. Some of those movies are good, some are even great in their way, but basically none of them (with one exception) seem to capture any but the most superficial aspects of his vision. There are probably many reasons for that, but one is that PKD's heroes are almost uniformly schlubs, and while it is possible to make a movie with a schlubby hero, it is not possible in the context of a summer-sf-blockbusters. The only movie to really be deeply Dickian, that is, to use the cinematic medium in such a way as to convey the actual themes of Dicks' work, is the neglected A Scanner Darkly.

Dick returned over and over again to certain themes, one of which I also seem to return to: empathy, and its absence. There are at least two great inventions of his in Do Androids Dream of Electric Sheep (which formed the basis for Bladerunner) – The Voight-Kampff machine which could distinguish replicants from humans by measuring their empathy and the religion of Mercerism. The former made it into the movie; the latter did not, which is a pity, but maybe it is another one of those things that does not translate to movies. Mercerism was a kind of jacked-in version of Christianity where believers can share in the sufferings of William Mercer by means of an electronic device. This kind of thing – the sharing of actual spiritual presence over the intertubes – is something we are quite a long way from but I can't imagine it not happening eventually.

The idea (but not the actuality) of empathy pervades Dick's world. His characters all seem to be either casualties or agents of its absence. They are trapped in "a maze of death", which is none other than the universe itself, seen as a cruel machine manipulated by sinister false gods. Their make pathetic attempts to cling to one another for support, but find the others either unwilling or unable to provide the needed warmth. Genuine empathy, the shadowy presence of the true god blocked by the constructs of the demiurge, exists but only can be seen in glimpses.

Now that it occurs to me, the parallels between the Dickian and Kafkaesque are too strong to not see, and I feel vaguely embarrassed by not having grasped them before now, given that they are two of my favorite writers. Probably they too obvious to list, but one that strikes me is the combination of metaphysical terror with genuine if mordant humor. In Kafka, the machinery of death is composed of bureaucracy and the stuffy social structures of prewar Europe, while in Dick they are built out of automation, warring corporations, and drugs. Same shit, different eras – we are all trapped in these alien-yet-familiar systems, systems built by humans but in the process of spinning out of human control.

Dick's universe is a little less bleak than Kafka's perhaps, since he allows the occasional emanation into the false universe of magical life-restoring substances from beyond its boundaries. Thus the title substance/product of Ubik reveals its true nature in epigraph of the final chapter:
I am the word and my name is never spoken,
the name which no one knows
 
I am called Ubik, but that is not my name.
I am. I shall always be.
[update: well, that was -- different. I thought I was a PKD devotee, but I was a mere tourist amongst these people who in many cases knew the man personally, and have devoted years of study, and have internalized the man's enormous sprawling oeuvre.  Many serious scholars too, which I didn't expect. PKD is about fragmenting and fluid identity (among other things), and reading his works has a subtle deranging effect on one's sense of self (true of all authors in a way, but Dick takes it to a whole other level). So to be in this crowd was somewhat like being on a PKD drug, and his spirit seemed to enter and animate everyone there, like a more benevolent version of Palmer Eldritch.]

Sunday, September 16, 2012

The Same and Not the Same

I like my last year's Rosh Hashanah post. But I can't write the same one twice.

The solar clock is about to tick again, so here we are, at a boundary between two chunks of time. Year past and year to come, entirely different from our humble embedded perspective, and so damn similar when seen from above. Variations on a theme, and year-to-come will be year-past soon enough. My past-self was wont to scoff at such arbitrary boundaries as secular or religious new year's days; my current-self, made less arrogant and more human by the tenderizing mallets of time, is more apt to latch onto them gratefully, as useful and stable landmarks amidst the chaotic swirl. But these two selves are also variants of some common prototype. They are the same, they are both versions of me, yet different.

"The same and not the same" is a rather koan-like phrase but I got it from the title of a pretty good book on chemistry, and as it happens I am starting a new job once again dealing with computational chemistry, which is looking to be the same and not the same as the one that got me out to San Francisco about 13 years ago. Back then my wife was pregnant with our second child who is now about to have a Bar Mitzvah, which is going to be the same and not the same as that of his brother, three years earlier. These two individuals, who in years past might have been thought of as rough copies of their parents, are working hard on differentiating themselves from us and each other, as is appropriate to their age. That process too has probably happened in much the same way for thousands of years, and is utterly different each time.

Another sage once said that history not only repeats itself, it stutters. More recently I read someone complaining that modern life was like trying to keep time to a shoe going around in a dryer (ie, as arrhythmic and unpatterned a sound as can be imagined). Change is accelerating; my ability to deal with it is diminishing, so the older I get the more I cling to whatever stable temporal patterns are available. This particular one has lasted a very long time, and part of the reason for that is its ability to sweep up even the dubious and reluctant into itself.

Friday, September 07, 2012

Illiterate Programming

For some reason, the group I am working with on a pretty complex Rails application does not believe in comments. They are big time adherents to agile methods, TDD, and that sort of thing, and the anti-comment stance seems to be a side effect of that. The reasons, I'm told, is that code should be self-explanatory, and also since comments can't be validated with tests they are likely to become outdated and inaccurate.

Well, the first reason seems like nonsense. I admit to sometimes taking that position myself, but I'm used to working in languages that have more powerful abstraction capabilities than Ruby (and so it is easier to shape programs to match human thought). And even there, it is almost always useful to put in some comments as guides. The Rails/Agile community seems to put a lot of thought into matching up user-visible structure, program structure, data structure, and the natural language ways to describe them, but their tools are really pretty crude and don't work in exactly the places where you need guidance.

For example, I ran across a method called sanitize_structure. Obviously this was supposed to take some representation of a (molecule) structure and produce a new one that had certain features removed, but what were they? There was no easy way to tell. And that's because this operation is not self-evident, it depends on domain knowledge that is not readily captured in standard Rails apparatus.

The second reason also seems pretty nonsensical. Yes comments may become outdated, but eliminating them entirely seems like having your legs amputated to get rid of toe fungus.

Now, this group works much more collaboratively than most places I've been involved with. And that means that perhaps code doesn't need to be as self-explanatory as I'm used to – instead, you are encouraged to go talk to people and get them to explain it to you. Talking is good, although it seems both inefficient and risky as a way to transmit software design information.

But I've really been missing the presence of English language in the code. I've tried addressing this technically – I found an Emacs package that lets me insert annotations into the code that do not get saved in the file but instead live in a side-channel. This means at least I can make my own notes and read them later, although nobody else sees them. And commit messages from source control are also a valuable source of human-scale explanations and design rationales.

A lot of agile seems to involve this kind of over-reaction to very real problems of earlier models of software development. But I guess this kind of over-reaction is fundamental to how any new thing establishes itself.

[to go up a few meta levels – I realized recently that the whole point of most of my work, including the commercial, research, and philosophical aspects of it, might be summed up as exploring ways for reconciling computational technology with the way human minds actually work. And given this, I realized that the agile methodology people might have something to teach me in that regard – that is one reason I took this job. I was pretty certain I would find adapting to agile to be a struggle, and it has been, but I think it will be a productive one. ]

[and more meta – I have been thinking about starting a different blog for technical stuff like this – having a technical blog seems to be practically a job requirement these days – but so far can't be bothered. I'll use tags.]