July 12, 2005

The Interpretation of Allegory

One of the benefits of reading several books at a time--even if you don't pay a great deal of attention to any of them--is that you automatically get ideas by synthesis.

I've been reading Freud's Interpretation of Dreams at the same time as a course textbook called Classical and Christian Ideas in English Renaissance Poetry. This last book sounds like crap, but it's actually pretty good, once you get through the title. It's about how medaeval people thought classical Greek and Roman ideas that had been written down way before Christ actually proved Christ's teachings 100% right.

It's also a bit of an survey about how this potpourri of classical and Christian ideas got used in poetry, with lots of examples. It's interesting, because it's a really good overview about how medævieal people thought.

So I've just been reading the chapter on "Allegory", and at the same time, I'm reading about how Freud lays down some ground rules for how the dream-work converts dream-thoughts into dream-content. Here's what those three terms mean. The dream-thoughts are the things that you're really thinking about when you're dreaming. The dream-content is the things that you actually dream. The dream-work is the mechanism that converts dream-thoughts into dream-contents. The result of this is that you never actually see the "real" dream-thoughts unless you look hard for them, sometimes with the help of Freud. What you actually see in your dreams is just dream-content, and dream-content is always very strange, because it converts dream-thoughts. Freud says that dream-thoughts are often things you don't want to know about. In your waking life, you repress them; in your sleeping life, you also repress them by converting them into unrecognisable images. And that's why dreams are always so weird: they try hard to be unrecognisable.

Anyway, at the part I was reading, Freud is laying down rules that describe, generally, how dream-thoughts get converted to dream-content. Like he'll say that if you have a thought X, then the dream-work will perform these certain operations to turn it into dream Y. The interesting thing is that, although the dream-content can turn out to be almost anything in the end, the operations performed by the dream-work are always the same.

A bit like XSLT, right?

Or a bit like a computer processor, see?

Anyways, so what I was thinking was, has anybody tried to apply, or at least discover, the rules that convert human narratives into allegory? Could this not reveal the same kind of rules as Freud has discovered for dreams? Let me just note a couple of Freud's conversion rules:

  1. dreams-thoughts get compressed
  2. dream-thoughts get displaced onto related thoughts
  3. if dream-thoughts and their related thought are both ready subjects for the dream, then the compression can happen through displacement
  4. when thoughts are displaced onto other thoughts, the dream-work considers which replacement thoughts will be the easiest to represent, and it rejects things that are hard to represent

That's the basics.

So could you uncover this same kind of stuff for allegory? Or at least for common allegory? Could you list the rules that operate when we transform a concept into an allegory? Because, when we do so, perhaps our minds always choose the representation of least resistance. Perhaps, given a subject, and given the context in which we are living, we will always create the same allegorical figure for it? I wonder.

I understand that there's a danger in over-analysing a mental process which happens to be conscious. As opposed to dreams, we usually reflect, and call upon all our mental faculties, when we are creating allegory. Nevertheless, there may be subconscious elements in it that it may be possible to uncover.

I wonder if anyone has looked into this. Probably somebody with a penchant for literature would have done it. Worth finding out.

July 08, 2005

Testing Absence

Welcome to the fourth edition of "High-Tech Programming", in which we discuss some of the fleeting-edge concepts and problems of modern-world technological computer development. In this issue, I would like to take a time-out in order to step back and reflect on one of the nastiest sources of error in programming today, namely, the test for absence.

The test for abcense is the situation, occuring at least once in every program, object, module, function, method, variable and parameter, of making the computer do something depending on if something else exists or not.

There are numerous complexities to the concept of "absence", whence the problem. Testing if a value equals another value is generally easy, but testing whether a value exists is mind-boggling, and most languages are specifically designed to make it as incomprehensible as possible.

Say I want to test if my social security number is greater than π, for example. It's easy. I just go:

if mySocialSecurityNumber > π

and I'm done. That works for credit card numbers, phone numbers, PIN numbers, recipes, you name it. But I start to have problems when I want to test if my social security number exists. What do I do? This:

if mySocialSecurityNumber = 0


That'll work in QuickBASIC. Sometimes. But in C it will reset your stupid number to 0 and tell you everything's fine. That's because... who cares what it's because. No language even bothers to follow any sort of standard for this sort of thing. Testing absence, something upon which probably trillions of dollars of transactions and millions of medical records depend on every second, is a completely random operation. To know how to do it right, you have to:

  • know what language you're using,
  • know how that language represents data structures internally,
  • know how the language's declaration mechanism works internally, and, by extension,
  • know how that language represents memory access; you also have to know:
  • what operators are available for each data type in each language,
  • if and how those operators can be defined, redefined or overridden,
  • the behaviour of the operator once it's been overridden, and
  • @&$#@% Perl!
  • You also need to know the distinction between:
  • whether a value has been declared,
  • whether a value has been defined,
  • whether a value is empty, or
  • whether a value is null.

I think this is a lot keep in mind for a totally elementary operation. And it's not just a question of intellectual effort: sure, if you spent enough time thinking, you could order in your head which type of test is necessary when, depending on the combination of the above factors, but in doing so, I think you're entering into a process over multiple layers of abstraction of the computer language. Really, when a language provides you with an equals sign, it should be capable of working on one level.

This is not a joke. A language like C can be very handy if you're willing to keep track of on which level of abstraction your code is performing each operation, but when we claim to be moving towards more normalised, readable and maintable code, a language can easily make a clear distinction between processes at the level of memory, and at the level of, say, representing a bank customer. In other words, "Smith, Joe", has nothing to do with RX0DX.

July 05, 2005



I haven't had any, but the Perrier is 0.80 €. In cans.