"You are not expected to understand this."

Some long chain of internet wandering this morning brought up this classic comment by Dennis Ritchie: "You are not expected to understand this." (Follow the link for context, if you get programming; otherwise, you might want to skip most of what follows and just read the end of this post.) Reading dmr's explanation, it reminds me of a great many instances of arcane code in theology. Spots which are hard to believe, until you get down to trying to hack around them, and discover that it is reality which is bent, and the code is just following the hack in the world. Which is just as much as to say that the machine and the language don't line up, like in any paradox. It's not the language's fault. But it's also an indication that the language is built for flaws in a very specific model, and when the model changes, so do the flaws. Old ones disappear -- not always because they've been fixed -- and new ones pop up in unexpected places. New language, new code, is required.

Understanding the theological code from Nicaea to Chalcedon, for example, requires you to understand the machine it was coded for -- the basic assumptions of the model of the world at the time. The Fathers were hacking on machines that had a lot of functions ours don't (speaking in terms of metaphysics), but lacked a lot of functions we take for granted. It's hard for a modern to really understand Aristotle and Plato at the gut level. Think of 5th-century metaphysics as the PDP-11/45 of its time.

And, after a dark period, medieval scholasticism acquired the last working reconstructed PDP-11 and its translated, annotated and argumented manuals from the Islamic scholars. Over time they built a VAX out of them -- extending the basic PDP design, making a new system that worked in very similar ways but could address a wide range of new questions. Think of the medieval scholastics like virtuosic VMS programmers, capable of making the system answer any question they could think of -- in VMS -- but with no good way to check the answers in corner cases. Answers that made perfect sense in the terms of the operating system, that made perfect and even strenuous use of the facilities provided by the hardware -- but for that reason might have only returned "true" because of matching bugs in software and hardware.

Nominalism, for one example: "facere quod in se est." The system, with its hard-coded split between memory domains, can't answer questions that require crossing between them, and returns the "it's up to you" message to the operator, but that should have been read as an error code, not an answer. "Facere quod in se est" should bear Ritchie's code comment -- "You are not expected to understand this." I.e., "this is the hack that works with the design of this machine, we know it's ugly, but don't screw with it; the system doesn't allow any better solution." Writing code that solves problems that cross between the domain of nature and the domain of grace (the domains of the creature and Creator, respectively) means working against the metaphysics we've inherited. And to the extent that it might be nice to have a machine without that limitation in its logic, we're still trying to build one today!

Basically, Luther is famous for being damnably persistent about bug reports that the administrators kept filing as "Solved -- user error." And Luther was a master and doctor and professor of the system, as well as of its internals. He had studied the Magister sententiarum, and he had learned to hack around the bugs in the system using the standard interfaces. He was trained in Nominalism against the Scotist position, which is to say that he preferred the separation of nature and grace, along the lines of essence and existence, to a sense that what is simply is what it is. (We're still programming around that Aristotelian conceptual division today, rather than the Socratic skeptical analytic of Plato.) But (and I owe this to Oberman) Luther slowly backs away from the "facere quod in se est" free will answer for domain crossing. And Romans marks the serious break from it. He starts coding something else. If we're stuck dealing with the domain-crossing problem, the bug is that we keep trying to write code that crosses into divinely protected execution space. And the program always comes back with something interesting and unexpected when you try to do that. More or less subtle bugs because they don't handle the restriction correctly. The answer is that only God can cross the boundary into userspace. You don't need to code for that; root handles it. Program like the answer exists, not like you have to come up with it yourself.

Ultimately, the lesson I take from Ritchie, via my theological analogies, is this: anytime you run into a nettlesome theological position where the comments say "You are not expected to understand this," remember that the system administrators put it there because they saw that the bug was in the machine, and they couldn't find a better workaround. They did what they could to make code that would run on the system they had, with the tools they had. Figure out where the bug was, and where it is now. Don't learn the lesson that Ritchie is God -- remember that Ritchie was where you are. Write the best code you can for the limitations of the machine you have, and leave at least halfway-decent comments to warn the next person. And have a sense of humor about the whole deal. Because in the end, your program only runs because and to the extent that God takes it up.