Well, it took some provoking, but (Connect-&-Empower) Dave Rogers rose to the bait of an archaism in the conventional translations of the Lord's Prayer. Dave thinks that "hallowed" doesn't belong in a contemporary translation of the passage, and I'm inclined to agree with him.
It's actually beenbothering me for a while. The Greek word agiasthetw is one of those third-person imerative forms of a verb that means "to saanctify, to make holy." So Dave's right (in his comments) when he observes that substituting "honored" misses some of the force of the Greek verb. We honorWorld Series champions, but we don't hallow them, sanctify them, or otherwise render them the opposite of profane.
One of the problems the translator faces involves a modern Western cultural reticence about "holiness" in general. A whole variety of useful words related to worship and sanctity (words like "pious," "devout," "sanctity") have been siphoned into unsavory discourses that make them less suitable for colloquial use. "Pious" and "devout" can sound smug and prissy; "sanctity" has been so abused by unctuous politicians that one might be excused for wishing that nothing be sanctified again for a long, long time--especially not The American Family, the Flag, Tax Cuts for the Super-Wealthy, so on.
So while I agree with Dave that "hallowed" ought to go, I'm just not moresatisified with any particular alternative.
But while we're on the topic of translating from the Greek, today Dave Hedges asked what's with the difference between the conventional contemporary Lord's Prayer's "Save us from the time of trial" and the archaic "Lead us not into temptation." That's a tricky one, too. The main verb is a plain word for "to lead in," so that the older version captures that bit quite adequately. The contemporary version substitutes "Save," which seems unduly confusing to me; Jesus isn't talking about "saving" here in the sense of "saving lives" or "saving souls" as he does elsewhere; he's saying "Don't lead us into. . .". But what's with "time of trial" and "testing"?
The Greek word involved has historically been used for "testing," usually in a fairly neutral sense. At some point either because of New Testament usage or in close proximity to New Testament usage, it begins to show overtones of "testing" in a hostile sense (hence, "temptation"). The scene in the wilderness after Jesus' baptism can quite plausibly be rendered as the "testing" in the wilderness (rather than "temptation" in the wilderness), and doing so brings out nicely the echoes of Israel's experiences in the forty years of wilderness wandering. Eventually the Greek word has pretty clearly accommodated a hostile sense for "testing" as part of its range, though it still workss well for just plain testing (and I acknowledge that some poeple will look on any kind of testing as hostile). So contemporary translators judged it most likely that in the Lord's Prayer, the word refers to The Ultimate Test, the Day of Judgment, from which disciples asked to be rescued (not implausibly, since elsewhere Jesus instructs disciples to beware the presumably unpleasant manifestations of the Day of the Lord). Back in James I's day, though, the predominant opinion held that this petition simply went, "don't lure us into spiritual danger," something of an odd request to make of a God one is supposed to love and trust.
My friend Jeffrey Gibson has written a strong article about "testing" and how it turned into "tempting." He's pretty well convinced me, and I'm ready to begin saying "Do not lead us into testing." (Why can't we use contractions in church? Of all possible colloquial usages, contractions seem minimally improper, and they form a standard part of daily discourse. Who would ask a friend, "Do not lead me into the chocolate store" rather than "Don't lead me into the chocolate store"?)
I'm still working on "hallowed," though.
Maybe tomorrow I'll talk about the "Son of Man."
Posted by AKMA at October 29, 2002 11:06 PM | TrackBackI believe that there was a 'testing' version in the 70's. Didn't it say 'Do not put us to the test.'? Or is that just too demanding of G-d?
Posted by: Susan at November 1, 2002 03:56 PMBeing able to understand that basic idea opens up a vast amount of power that can be used and abused, and we're going to look at a few of the better ways to deal with it in this article.
Posted by: Bellingham at January 13, 2004 01:46 AMNote the new asterisks whenever we reference favoriteNumber, except for that new line right before the return.
Posted by: Thomas at January 13, 2004 01:47 AMThe most basic duality that exists with variables is how the programmer sees them in a totally different way than the computer does. When you're typing away in Project Builder, your variables are normal words smashed together, like software titles from the 80s. You deal with them on this level, moving them around and passing them back and forth.
Posted by: Barnard at January 13, 2004 01:47 AMThat gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.
Posted by: Edward at January 13, 2004 08:38 AMInside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.
Posted by: Richard at January 13, 2004 08:38 AMWe can see an example of this in our code we've written so far. In each function's block, we declare variables that hold our data. When each function ends, the variables within are disposed of, and the space they were using is given back to the computer to use. The variables live in the blocks of conditionals and loops we write, but they don't cascade into functions we call, because those aren't sub-blocks, but different sections of code entirely. Every variable we've written has a well-defined lifetime of one function.
Posted by: Florence at January 13, 2004 08:38 AM