Waystination

A Christadelphian Reading List

noreply@blogger.com (Len Budney) — Mon, 22 Feb 2016 16:00:00 +0000

In a previous post, I mentioned the "enormous amount of material" I'd read to learn about the Bible, and my community's views on the Bible. This post will summarize that, in case you're curious. It really is "enormous," so you probably won't read much of it, but you might find interesting bits to skim. I'll summarize them here, and give links you can read online. (Note: various folks post these books on their web sites; linking to them doesn't mean I agree with them or that they represent the Christadelphians.)

1) Elpis Israel, John Thomas, 1848. (read online)

This is the "original" Christadelphian book: the Christadelphians grew out of the readership of a magazine by John Thomas, most of them Campbellites. Thomas gradually parted ways with Campbellite teaching over a couple of decades, until he was finally expelled. Somewhere along the way his readers asked for a summary of his views, and he responded by writing this book.

As the first book it's highly respected, but it doesn't dictate Christadelphian belief (except in the eyes of a very small minority). There are things in the book that few would agree with today. Although someone who agrees with John Thomas will certainly not be considered a heretic, however in the minority he may be.

That's especially true of Part III. It's a good overview of Thomas's views on Bible prophecy. Till recently a majority of Christadelphians agreed with him. A growing minority disagreed with almost everything he said, and they were free to do that without repercussions. At this point I'm not sure whether Thomas's views are the majority view or a minority view.

2) Christendom Astray from the Bible, Robert Roberts, 1884. (read online)

Originally called "Twelve Lectures," this book is based on a series of lectures by Robert Roberts spelling out the basic teachings of the Christadelphians. As the title implies, it mostly talks about "standard" Christian beliefs that Christadelphians disagree with, like the Trinity, the immortality of the soul, a supernatural devil, heaven-going, hell, etc.

3) God's Way, John Carter, 1947. (read online)

When my family started our first Bible study with the Christadelphians, this was the book we used. It's shorter than either of the previous two. It's more readable than Elpis Israel, which is very much a 19th Century book. And it's more upbeat than Christendom Astray: instead of attacking mainstream Christian teachings it first positively advances Christadelphian teachings. And then it attacks mainstream Christian teachings. Each chapter has a "Part II" that compares the teaching in Part I with mainstream Christian teaching.

4) Phanerosis, John Thomas, 1869. (download PDF)

The linked PDF is prefaced with about 30 pages defending the book from critics. The book itself begins on page 29. As you can guess, some of the material is controversial.

This book outlines what Thomas saw as the core teaching of the Bible: that God's entire purpose is to make people into "His image," reflections of Himself, and that He operates through agents who get to speak in his name, or even in select cases be equated with God himself. Jesus, and the angel in the burning bush, would be two examples of this. Both are called God and/or referred to themselves as God, but neither actually was God. This doctrine drives Thomas's interpretation of Bible passages that seem to identify Christ with God, since Thomas rejected the doctrine of the Trinity.

While Thomas's view here is defensible, and some modern theologians who aren't Christadelphian would agree with him, there are defects in this work. In a way, these defects speak to a fundamental handicap of most Christadelphians. Thomas bases his idea on careful arguments about the original languages, mostly Hebrew, but Thomas himself was not a Hebrew scholar. He was a layperson who was decently competent with reference materials and at least somewhat read in the scholarship of others. Not all of his arguments hold up. To this day few Christadelphians are scholars of the original languages, and we continue to labor out of our depth in this area.

5) Other misc. works by John Thomas (see here for quite a few of them)

John Thomas wrote rather prolifically, and a well-read Christadelphian would be at least familiar with a lot of it. He also edited more than one magazine, over more than twenty years, which are still available. See here for example; they have eleven years' worth of his Herald of the Kingdom and Age to Come.

I've read almost all of this material over the years. Obviously most of it I've read only once, and I probably skimmed a fair bit of it, so only so much has stuck with me, but as you can imagine it's enough to keep one busy for a very long time.

One of the funniest things in the collection is an actual catechism written by Thomas. It's funny because a lot of his writings savaged the Catholic church, especially for its creedal nature. The Christadelphians also adopted a statement of faith (i.e., a creed) in 1877 (PDF), six years after Thomas's death.

The Making of a Christadelphian, Part 3

noreply@blogger.com (Len Budney) — Mon, 15 Feb 2016 16:00:00 +0000

This post is really part four. This series starts with an Overview of the Christadelphians, followed by my own story leading up to my baptism, and then a description of our theology masquerading as the story of my early post-baptism Bible study.

I was somewhat (but not terribly) unusual because I got baptized at age eleven. I was even more (but still not terribly) unusual because I was a convert, who got baptized at age eleven. This put me in a weird position in our community. As I said in my overview, we are a lay, patriarchal, millenarian, unitarian, evangelical, apolitical, community of Bible students.

The first problem was what to do with an eleven-year-old brother in a patriarchal community. Kids my age attended Sunday School, and Sunday School was generally taught by women. But the rule in our community is that women don't teach men, by which we mean baptized males. So as soon as I was baptized I was pulled out of my Sunday School class--but nobody really knew where to stick me. For a while they tried putting me in the adult Sunday School class, but I didn't enjoy it much. Then they found a brother willing to teach me for a while, which lasted until he finished his degree and moved away. Then they decided the solution was to make me a Sunday School teacher myself, and from then on I taught a precocious five-year-old one on one. This lasted about a year, until my family moved away and we stopped attending for a while.

The second problem was what to do with an eleven-year-old brother in a lay community. Every baptized brother (remember, patriarchal) is normally expected to take a turn leading the services on Sunday, giving the sermon, leading Bible readings, etc. This problem was handled by ignoring it: they simply didn't ask me to do those things because I was "too young." That's sensible enough, but it came up surprisingly often. Do you? You don't? Why not? When will you?

After a year or so they started calling me up to do the scripture readings. That was all, until I was about sixteen. A few things happened around that time. I started attending Community College full-time at 15 1/2 (a story for another time); I found a nursing home that would hire me as a nurses' aide at 16; and the church decided that it was about time I started giving sermons. This lasted a couple years, until I transferred as a junior to Brown; at that time the church secretary, who disliked my family, unilaterally dropped me from the speaker list. ("Oh. I didn't realize you'd be coming home every weekend and attending church. Too late now, though.")

Over the years between ages eleven and eighteen I was doing the "catch up" Bible study described in my previous post. On the one hand I covered an enormous amount of material (which I'll give links to in a future post for the curious). On the other hand, it was pretty much all Christadelphian material. So while it felt like an enormous education, and in some ways it was, this education took place in a bit of an echo chamber. There was an enormous amount of material I wasn't learning, which I'll get to in the next couple of posts.

The effect of all this was that I wasn't only learning about the Bible; I was also learning about my community and its views and standards. And I wasn't only learning about these things; I was also starting to enforce those standards on myself and others. That's what I'd like to look at in my next installment.

The Making of a Christadelphian, Part 2

noreply@blogger.com (Len Budney) — Sat, 12 Jul 2014 14:48:00 +0000

This post is really part three, to be technical: the first part was really an overview of the Christadelphians. Part 1 of my own story summarizes how I came to be baptized at age 11. In a nutshell, I always believed in God (apart from a one-day flirtation with atheism at age 5 or 6), and was always some sort of Christian (a half-baked Catholic who did not often attend church, but when I did it was Baptist). I believed the Bible was God's word. When we discovered the Christadelphians, their emphasis on Bible study--and the fact that their beliefs seemed well-supported by scripture--made joining them the obvious choice. We joined them because they encouraged us to question and doubt what they taught, and because they agreed that even believing the Bible or believing in God's very existence was conditional on evidence.

Not that I spent much energy questioning the Bible or God's existence. I already believed those things. When I did, it was focused mainly on evidence supporting the Bible; if the Bible is divine, then God's existence follows automatically. So I read about archaeology proving that the Bible was historically accurate, like the discovery of Sargon's Fortress (Dûr-Sharrûkin) that proved King Sargon of Isaiah 20:1 was a real historical figure after all. And I read about prophecy, especially the prophecy that Israel would be reestablished, as Christadelphians had been saying at least since Elpis Israel was first published in 1848--exactly 100 years before it happened. And I savored Undesigned Scriptural Coincidences, which listed dozens of examples of internal consistency in the Bible. All of this was mostly recreational reading for me, though, since I already believed.

What really consumed me was general Bible study. I read the Bible daily with my family, following the daily reading planner used by most Christadelphians. It took us through the Old Testament once, and the New Testament twice, every year. Christadelphians are certainly Bible readers. All of them have read the Bible through several times. The ones who "do the readings" faithfully will read it dozens of times before they die. They can remember any story you care to mention, and can quote swaths of it from memory. Christadelphian kids by age eleven have read the Bible, or had it read to them, a half-dozen times already. Becoming one at that age meant I was already behind the 8-ball.

Catching up meant doing those readings, paying attention in Sunday School, and reading on my own. I read lots of books, mostly written by Christadelphians. Elpis Israel was the first book ever written by a Christadelphian, and still considered a classic about our main beliefs. Christendom Astray (PDF) was another early work that contrasted our beliefs with those of most other Christian denominations. The list is long, so I won't give it here. Many of our books are available online, if you'd like to peruse them.

As I mentioned in previous posts, we are heavily biased against studying theology. A look at the contents of Christendom Astray will tell you why. We believe differently than most other denominations, and we generally assume that their flawed beliefs are the result of flawed theology. How would it help us to study flawed theology?

Nor did we create an alternative theology of our own. Well, anyone who thinks about the Bible is doing theology, whether they want to or not, but we refused to try and systematize it. That smells too much like dogma to us. We don't like dogma, and for that matter we don't like hierarchy. We believe that anyone can "understand the Bible for himself," as our lectures and pamphlets say, and we don't believe in interfering with someone else's conscience. If your conscience leads you to different beliefs than ours, we may not let you join our churches, and we may confidently tell you you're wrong, but we don't claim authority over your conscience.

But we do have a theology whether or not we systematize it. We teach it by example instead. Reading Christadelphian books and magazines gives plenty of worked examples of Bible study. So do our weekly Bible classes and evening lectures. We all learn how it's done by imitation.

The first thing I learned was to "read the plain sense." If the Bible is a book for all times and cultures, meant to be understood by ordinary people without fancy degrees, then its message must be relatively plain. So if the Bible seems to be saying something clearly, then it is.

The second thing I learned was to "read the Bible in context." If a verse says, "Oh, Lucifer, look how you've fallen from heaven!" we don't leap to the conclusion that "Someone named Lucifer was up in heaven, and he fell down!" We read the verses before and after it (it's in Isaiah 14), and we notice that the first four verses say, basically, "When you return from captivity in Babylon, you will sing this taunt against the king of Babylon." It's clear from context that the bit about "Lucifer" is part of the taunting song, so it's clear that it's the king of Babylon who is called "Lucifer" (for whatever reason), and his "fall from heaven" refers to the fall of Babylon's power.

When we talk about "context," we also talk about historical context. We try to inform ourselves about the history, customs, and geography of Bible times. Many of us subscribe to Biblical Archaeology Review. We're somewhat uneven in how deeply we go into it, but we try.

The third thing I learned was to "compare scripture with scripture." This is where it gets interesting. We know that you can find verses that contradict each other ("...when taken out of context!" we hasten to add). We know that some passages are more obscure than others. But we assume that IF the Bible is God's word, THEN it must ultimately have a consistent message. The points and counterpoints must fit together, like brushstrokes, to paint a picture. Our job is to collect the verses, back up, and look at it until the picture comes clear.

By the way, didn't I just contradict myself? I said at the top of this post we demand evidence before we believe. Aren't Bible contradictions evidence against the Bible (and therefore God)? And didn't I just say we assume them away? And doesn't that mean we reinterpret the Bible to paper over contradictions? Which we then claim somehow proves God?

If we're not careful, then yes. If we really want to, we can explain almost anything away. There's a whole blog out there devoted to the ways we fool ourselves.

On the other hand, apparent contradictions are a fact of life in general. If I tell a story twice, details will probably differ. Some overly-literal people will ask me which time I was lying. (No, really, that's happened to me. I've come to the conclusion that the wisest course is just to avoid people like that once they've outed themselves.)

This is standard stuff for historians (as I understand it; I'm not one). When we read copies of copies, of translations of translations, of stories that may be preceded by long oral traditions, how do we sift fact from fiction, or truth from error? There are ways, but it's not easy.

It's also standard stuff for ethicists (as I understand it; I'm not one). Isn't it a contradiction for "pro-lifers" to be pro-death-penalty? Yes, if you oppose all killing (including the unborn). No, if you believe that certain crimes forfeit the right to life. Isn't it a contradiction for a pacifist to eat meat? Yes, if you oppose any violence against any creature. No, if you distinguish humans from animals. Isn't it a contradiction to say, "Thou shalt not kill," and then command people to go to war? Yes, it certainly sounds like it. But no, if you read it as, "Thou shalt not murder," and you believe warfare isn't murder.

So there's no way around "comparing scripture with scripture," and it's a delicate business to resolve seeming contradictions while remaining open to the possibility that there are genuine contradictions there. I think closing our eyes to this possibility is a common way to lapse into fundamentalism.

The Making of a Christadelphian, Part 1

noreply@blogger.com (Len Budney) — Mon, 30 Jun 2014 19:45:00 +0000

My previous post was just over a year ago. On rereading it, I'm still pleased with it as a fair and balanced description of the Christadelphian community overall. From there I originally planned to branch off in two directions: first, to go into more detail about Christadelphian beliefs; and second, to go into more personal detail about my growth in the community. I'd like to tackle the second first.

This isn't my "personal testimony," if you've seen that sort of thing before. It's also not meant to be autobiographical, except to the extent I can't help it since it's about, well, me. The point of this post is to sketch how one person came to join "a lay, patriarchal, millenarian, unitarian, evangelical, apolitical, community of Bible students," what that person found when he got there, and where it led him.

I do intend to be painfully honest about my shortcomings, including doubts or weak spots in my faith. It's not because I want other people to doubt along with me. It's because I'm not trying to convince anyone that I'm a hero of faith; I want to be honest about my doubts as well as my beliefs. You're free to take comfort that you're not the only doubter, or set me straight, or decide that I'm an inadequate Christian, as the case may be.

Childhood: A (not-very-good) Catholic

My Dad's side of the family is Polish, so naturally I became a Catholic by default. I was christened, and a well-to-do relative (whom I've never met, unless he was there for my christening) was named my godfather. After that I have no memory of ever attending church--when I was about 7, I went to a Catholic funeral with my Dad, and when he genuflected I rushed to grab his arm and help him back up, because I thought he had tripped.

Needless to say, I was never confirmed or given first communion. My parents sent me to catechism class for about a year when I was 5 or 6, though I don't know exactly why, and we didn't go to church that year either. There the nuns taught me to cross myself, say the Lord's Prayer and the Hail Mary, and to give things up for Lent. We were working on the Act of Contrition when my parents moved, and my religious education came to an end.

Although I never saw the inside of a Catholic church--as far as I can remember, apart from weddings and funerals--I did go to church with my cousin sometimes. We regularly had that conversation (I'm a Catholic. Well, I'm a Baptist.) but neither of us knew what the difference was. My cousin went because his mother made him, and I went because I was sleeping over.

Around the same age, sleeping over my cousin's house, I announced that I didn't believe in God. I'm uncertain what prompted it, but I believe it was watching a rerun of the premier episode of "All in the Family," in which Michael and Gloria said, "We just don't see any evidence of God." Naturally, my cousin tattled at Sunday School the next morning. The teacher turned her full attention to me and asked me why, so I repeated what I'd said the night before. She said, "Oh yes, there is a God, and he loves you very much!" I answered, "Oh, OK," and from then on I believed in God.

Also around the same age, I had my first brush with death: my Aunt Gertie died, shortly after attending a big family dinner at my great grandfather's house. I didn't know her; my memory of her was an old lady walking around the yard with a big, heavy cane. But when my Mom got off the phone and announced that she had died, it sparked the usual conversations about what that meant, leading to the realization that it was going to happen to me, and triggering my first bout with depression (though I was too young to articulate what was going on, and I don't think anyone knew). Funnily, my parents had a music box of a dancing bride and groom that played "Theme from the Godfather," which Mom wound up every night to put me to sleep. For years afterward, hearing that waltz would depress me.

That age also marked my first and last attempts at Bible reading for some years. I had the usual book of Bible stories for kids, which I read to myself. It led off with Adam and Eve bringing death on themselves and everyone else by eating the apple that God for some reason stuck in their garden, after a conversation with a snake that God for some reason put there. The story made me mad at Adam and Eve, and a little mad at God, but mostly it triggered more depression. I avoided reading the Bible for the next four or five years.

Later Childhood: A Convert to the Christadelphians

When I was about 10, my parents took a fresh interest in religion. My mom signed up for catechism classes. For some reason they didn't sign up my sister or I, but they did get us the books, so I started to read them. I also started reading the Living Bible, and my sister started reading the NIV. I read the gospels over and over again, and also started (hesitantly!) reading from Genesis. I got all the way through Kings that year. I still found Genesis 3 to be painful, and to that I added Genesis 11, which in the "Living Bible" gives the distinct impression that God sabotaged human progress because he was afraid they might someday pose a serious challenge to him.

I was ahead of my years in that I read the material easily and learned it quickly. I was also way, way behind, for lack of any meaningful religious education. I was quickly learning at age 10 what children normally learned a few years younger. I was also reading my Mom's adult catechism. A lot of the material has slipped away in the years since then, but at the time I was catching up quickly on the theory, such as the sacraments. Memorizing prayers wasn't much fun, so I didn't learn much liturgy.

At the same time as we attempted to re-join the Catholic church, we were shopping around a bit. I read Watchtower publications that my great grandfather bought from passing JW's just to be polite. I read the weird, new-agey Science of Mind magazine, which my grandmother received for some reason. I read books on Eastern religions, and books by Wiersbe. There wasn't much structure to my reading, and I ended up with a smattering of everything rather than any real depth in anything.

In the midst of all this, we ran across the Christadelphian booth at the New England Fair. It was strategically located near the Vitamix demonstration, which is a story in its own right. The Christadelphians appealed to us almost instantly, because their core values were about the same as the ones we'd developed by this point. Within a year of meeting them, I began taking regular Bible classes with them, and was baptized in early 1982, aged 11. My parents were baptized a month or two later.

My Core Values and Beliefs

At the time I was baptized, the following were my core values and beliefs. As you'll see, they're in logical order, but not quite in order of importance.

There is a God

As I said above, I just believed this ever since a baptist Sunday School teacher assured me of it when I was 5 or 6. I didn't subject this belief to rigorous reexamination, and wasn't equipped to if I wanted to at the age of 10. I was bright, but not that bright. But the usual apologetics were good enough for me--mainly, the argument that the Bible is His word, and therefore he must of course exist. Which brings me to:

The Bible is God's Word

It sounds like I just set up a circular argument, but the argument that the Bible is God's word doesn't have to assume there's a God in the first place. Again, the usual arguments were good enough for me. The Bible is full of uncanny fulfilled prophecies--notably the reemergence of Israel, which Christadelphians had been confidently predicting for almost exactly 100 years before it happened. It's a self-consistent document, meaning that what contradictions there are either (a) can be explained away fairly easily, or (b) just aren't that important. It was ahead of its time, with clever advice like avoiding pork or shellfish, and practicing good hygiene. Etc., etc. The conclusion is that the Bible is a "supernatural" book, which implies a "supernatural" author. Therefore God.

The Original Meaning of the Bible is the Correct One

In other words, whatever people in Jesus' day understood the New Testament to mean, that's what it means. Whatever the people in Moses' day understood the Torah to mean, that's what it means. This seemed self-evidently correct to me, and it naturally led me away from Catholicism. There's no question that biblical interpretation evolved over the history of the Church. For example, any good scholar--including Catholic scholars--will admit that the first century believers didn't have any conception of the Trinity as it came to be formulated over the next three centuries. This isn't a problem for Catholics, because nothing says their understanding of scripture can't evolve. It was a deal-breaker for me, however, because I was only interested in understanding scripture the way the first disciples understood it. Rejecting post-apostolic beliefs effectively ruled out a post-apostolic church.

We can Understand the Bible for Ourselves

That is, we can figure out how the first believers understood the New Testament, and how early Israelites understood the Torah, without the need for theologians or priests to interpret it for us. This is the other belief that led me away from Catholicism, since the Church reserves to herself the prerogative of interpreting Scripture.

Truth is the Most Important Thing

A common refrain among Christadelphians is (or was, at the time), "If you can prove this Bible wrong, I'll throw it away." Variants included, "If you can disprove God's existence, I'll stop believing in Him," and, "If you can prove my beliefs wrong, I'll trade them in for whatever's right." The key idea here is that, in principle at least, our goal is to pursue whatever is true regardless of the cost.

This last value actually takes priority even over God's existence (again, in principle at least). I believe in God, and that the Bible is his word, but I'm willing to let go of both beliefs if they turn out not to be True. You might ask what would ever convince me they weren't true, and that would be a good question, but the fact remains that I'm open to the possibility that I'm wrong about God's existence, and I'm willing in principle to give up my religion if that turns out to be the case.

Pleased to Meet You! Hope You Guess My Name!

noreply@blogger.com (Len Budney) — Thu, 06 Jun 2013 13:44:00 +0000

On this blog, and elsewhere on the Internet, I talk about my religion. This post is a thumbnail sketch of the community I belong to.

My denomination is a very small community. It's found worldwide, but all together we have about 60,000 members total. We call ourselves "Christadelphians," and we believe that we've managed to recreate the first-century Christian community. Well, we haven't recreated their practices, and I think most of us know that. Our practices come from our founding, in the 19th Century, and resemble the Puritans and other Protestant denominations like that. But we believe that our beliefs are extremely close to those of the 1st Century. I'll talk about our beliefs another time.

Within our community, almost everyone knows almost everyone. And we have some fairly strict social norms. For the vast majority of Christadelphians, we are a lay, patriarchal, millenarian, unitarian, evangelical, apolitical, community of Bible students. What does that mean?

A lay community. That means we're a community of laymen. We don't have any clergy. Everyone takes turns leading the service on Sunday, or delivering the sermon, or performing baptisms or weddings. Everyone teaches, and everyone preaches, with few exceptions. Nobody is "ordained." In fact nobody ever seeks an education in theology, Bible scholarship, or any related subject, with extremely few exceptions. We're not only laymen; we're self-taught.

Patriarchal. That means we're laymen. The men teach, preach, perform baptisms, etc. Women do not fill those roles. The few Christadelphian churches where women do those things, are considered extreme. In principle, it also means that the husband is the head of the household. In practice, most Christadelphian men would blush to "rule" their household in the way that a 19th-Century husband would consider a matter of course. But the average Christadelphian household is definitely an unequal partnership.

Millenarian. That means we believe that Jesus Christ will literally return to the Earth, literally resurrect the dead, and literally set up a world-wide kingdom that will last for 1,000 years (that's the "millenium" in "millenarian"). This, or something close to it, was generally believed in the 1st Century. Millenarianism has enjoyed surges of popularity over the centuries, including the 19th Century when our group was founded, but today that belief is at a low ebb, and we are one of fairly few denominations that actively believe this. (Technically, the Catholic Church teaches a version of this, but it's so severely de-emphasized that even most Catholics are unaware of it.)

Unitarian. That means we believe that Jesus is distinct from God. We call ourselves "biblical unitarians," to distinguish ourselves from "unitarian universalists." They believe that Jesus was just "a man with a unique relationship to God." We believe he was much more than that: he was literally the son of God, with only one human parent. That makes him more than human, and in fact makes him divine--without making him God himself.

Evangelical. That means we believe in preaching the gospel. Like most "evangelical" churches, we consider preaching one of our highest values. Often, this is to the exclusion of things like giving to the poor, doing charitable work, etc. In practice, fewer of us preach, and preach less of the time, than we'd like to believe about ourselves. That's not surprising, though: our ideal is so lofty that it comes with a heavy load of guilt, and to some extent we reduce the guilt by kidding ourselves. We try our best, though. (Note: we are not associated with the evangelical movement, even though we fit the general definition with regard to evangelism.)

Apolitical. That means we don't vote, don't campaign for political candidates or parties, and don't seek positions of rulership over others. For some, it means that we also refuse jury duty. For most, it means that we wouldn't even run for a spot on the local school board--I'm not sure whether any given Christadelphian ecclesia (i.e., church) would tolerate that or not. We consider ourselves "separate from the world," and politics is the epitome of "the world." We are also conscientious objectors to military service, for the same reasons.

...of Bible Students. Our very highest value is Bible study. Naturally, as with evangelism, that means we also deal with some guilt and some kidding of ourselves. Our study doesn't quite measure up to our aspirations, nor to our self-image. Nevertheless, as Christian denominations go, we are unusually committed to regular reading of the Bible and to thoroughly learning general Bible knowledge and also learning at least enough apologetics to preach and defend our beliefs. This makes us stick out from the rest to such an extent that our "Learning to Read the Bible Effectively" seminars usually attract lots of visitors from neighboring churches, and many of them continue attending our Bible classes for years--without ever leaving their present church--because, "Our pastor just doesn't know the Bible like you do." We're not very sophisticated students, sometimes, but we're very sincere and, often, very devoted students.

I believe that sums up my community in a nutshell. If anyone has something to add, or ask, or disagree with, then please feel free to comment below. Respectful comments only, please.

The perception IS the event

noreply@blogger.com (Len Budney) — Tue, 09 Apr 2013 14:21:00 +0000

A discussion recently happened in a private Facebook group that forced me to express something deeply meaningful to me. The group is for religious discussion within my denomination, and one participant said that he struggles with the discrepancies between the four gospels. To him a discrepancy between two witnesses means that one or both of them is wrong or lying.

Others had already replied with the standard response to this--because of course, Christians have a standard response. Eyewitness testimony seldom agrees perfectly. In fact when it does agree perfectly, jurors usually take it to mean that they cooked up their story together, and are lying. Discrepancies are a mark of authenticity. They show that someone didn't go through afterward and "fix" all the accounts to make them match exactly. Scribes must have been tempted to do it--in fact there are a few known cases where they did do it--but for the most part, they copied the text as it was, discrepancies and all.

I do find that argument persuasive. By itself it doesn't prove that the gospel records are true. But it disposes of the notion that discrepancies are a priori proof that one or more of them is false. The next thing to do is to look at the discrepancies and see if they're the sort of discrepancies you'd expect from eyewitnesses or not. But that's not the road I went down. Instead I replied (in part):

The problem here seems to be (1) a conviction that there's only one "true" version of an event, and any other version is therefore false, and (2) that inspiration involves God forcing people to report the one true truth. That view will lead you to throw your Bible away, because it's perfectly obvious that the Bible doesn't fit that description.

I'd suggest that every competent witness's version of events is equally valid, reflecting a different vantage point and different knowledge. Why would God force them all to recount things from His (probably incomprehensible to us) vantage point, rather than their own?

This didn't sit well with the other person, who suggested I was describing a completely novel definition of "inspiration." He asked, rhetorically I think, "Is it: 'the Bible is a record of people's human impressions of events' or 'the Bible is a record of events'?"

I see a false dichotomy here, between "human impressions of events" and "events." The events that we're talking about are human events, as opposed to, say, astronomical events. They relate to the interaction of two or more people. Or rather, an interaction of two or more persons' perceptions.

Think about an event in your own life. Ideally, an event involving conflict. To be concrete, suppose you're a man who has invited over some dinner guests, expecting his wife to do all the preparations, only to find her in pajamas, in a messy house, with no dinner ready. Your perception is that she disrespects you, or dislikes the guests, or is lazy, or something along those lines. Perhaps her perception is that she has a stomach bug, or perhaps it's that you never asked her before inviting these guests and she already told you that she wouldn't put together this dinner. There's an infinity of perhapses behind both of your behavior. Perhaps you planned the party in the first place to show her who's boss by making her prepare it. Perhaps she's in pajamas because it's your anniversary, which you forgot again, and now she's depressed.

The facts are thin soup: guests; messy house; wife in pajamas. Give 100 people those facts, they can write 100 completely different short stories. All of the meat of this event consists in both of your perceptions and motivations. That's what's interesting to the rest of us, hearing or reading about your I-Love-Lucy-style party disaster. And if you both wrote a synoptic account of this event, they would be different--perhaps unrecognizable as referring to the same event.

So what would be the "God's eye view" of this event? Possibly something on another plane entirely, like our perception of two hamsters fighting. But leaving that aside, I suspect that "God's perspective" on the "actual event" would be precisely to lay both of your accounts before us. It would be amazingly instructive to notice how both of you are "right," and both of you are "wrong," about the details of the event--but the event itself is the recounting of both of your impressions. That's what happened. Two sets of impressions collided.

The Bible sometimes reads like a dry list of facts, like a history textbook at its most boring. A parade of kings plods by, each one waging this war, or committing that sin, or fighting with the other prophet, and finally being "gathered unto his people" with a royal funeral and being "laid with his ancestors" (or sometimes not). But even those dry sections are full of editorial spin. Who says this king was "wicked"? Who says that king was "righteous"? Why is king Ahaz to blame for the three-year drought, rather than the prophet Elijah who actually caused it? Why is Ahaz hardhearted for refusing to conform to the Jewish temple worship, while people died of the drought, but Elijah is not hardhearted for refusing to relent on his curse until Ahaz breaks? See--it's all editorial spin. We're being told that Ahaz was bad and Elijah was good. We're supposed to take sides, and we're told which side to take.

The Bible is full of this, at every level. Practically everything interesting in the Bible is about someone's perception of events. Usually, we're supposed to agree with the author's perceptions, but not always. The book of Judges is one long mind-bending "what's wrong with this picture?" puzzle. We read about a man's concubine being raped all night long, and her husband cutting her corpse in pieces and mailing it all around Israel, like we're reading the score of last night's baseball game. The author deadpans the entire event, without a hint of judgment or even mild disapproval. We're left to ask ourselves, "Wasn't it bad to send his concubine out into a mob of rapists?" or, "Was it really appropriate to dismember her corpse?" or, "So, was the near-genocide of the rapists' tribe a suitable and proportional response?" The book of Judges raises all the interesting questions while refusing to answer any of them, and we're left frustrated--because we realize that the facts are not what's really important. What's really important is the perceptions of the people involved, and how we interact with them.

Life was GOOD in the Third Reich

noreply@blogger.com (Len Budney) — Fri, 14 Dec 2012 16:03:00 +0000

Seriously, it was. Obviously, it wasn't if you were Jewish, or Romani, or openly gay, a Jehovah's Witness or disabled. But how many people are we talking about here? The population of "greater" Germany, including Bohemia, Moravia, Prussia, etc., was 87.1 million people in 1939. The 1939 census of the Reich counted 318,000 Jews, including people deemed to have Jewish blood who would not be counted under Jewish law. Propaganda of the day estimated their numbers at closer to 1.5 million. There were something like 30,000 Romani living in Germany at the time. The number of homosexuals in Germany is difficult to determine, but it's estimated that up to 15,000 homosexuals were sent to the camps. Jehovah's Witnesses were banned, and some were sent to the camps; there were about 25,000 JW's in Germany. It's estimated that about 70,000 disabled were put to death by the Reich. So the persecuted population of Germany would be approximately 458,000 people. For good measure lets double that: 916,000 people. That's 1% of the population of Germany in 1939.

We never think about the 99%. We think about the 1% who died horribly, in a methodical program of extermination, and well we should. But if I asked you, "What was life actually like in Germany under the Third Reich?" you would probably talk about cattle cars, and gas chambers, and forced labor camps. If the experience of the 1% is what life was actually like, then life in America is all about flying private jets to Paris for a romantic breakfast of caviar and champagne. But no, I didn't ask about the 1%. I asked about the 99%. What was life like in Germany for the 99%?

You can get a glimpse of the answer in Milton Mayer's book, They Thought They Were Free. But the broad outlines are obvious: 99% of Germans never stepped onto a cattle car, never looked out through barbed wire, were never interrogated by the Gestapo or hauled off to Berlin, and certainly never died in a gas chamber. For 99% of Germans, life under Hitler in 1940 was no different than life under Friedrich Ebert in 1920. In fact it was immensely better! Under Ebert they experienced a hyperinflation so severe that the paper Mark in 1924 was worth one trillionth of its value in 1918. Under the Third Reich, the government resisted the urge to devalue the currency and so kept inflation in check. Hitler's nationalism inspired the ordinary German, not because the ordinary German was a homicidal maniac, but because he was sick and tired of being held completely to blame for WWI, of being forced to pay ruinous WWI reparations, of watching the plight of Sudeten Germans under Czech rule, etc.

In short, hyperinflation was a thing of the past. Reparations, an immense national debt, were repudiated. Guilt over WWI was repudiated, and Germans--the 99% of Germans we're talking about here--felt pride in their nation. Unemployment was down from 30% in 1932, to full employment in 1936, to a labor shortage in 1938. Economically, life in the Third Reich was the best it had been since before WWI.

And remember, these 99% never saw the inside of a concentration camp. They knew that Jews were being "resettled," but the "final solution" was not publicized, and certainly not any of the gory details. No German needed to think about where the trains were headed, once they left the station. The ordinary German was shielded from these horrors, and could easily live in denial that they were going on at all.

Similarly, we imagine Germans being challenged constantly with, "Ihre papiere, bitte!" But did they perceive this as the proof that they lived in a police state? Ask an American, who produces his driver's license on demand for police, who shows identification and removes his shoes and belt before boarding a plane, who shows his passport to return from Canada or Mexico, and who applauds the movement to demand proof of citizenship from hispanics, or the practice by New York City police of randomly stopping and searching people without probable cause. Ask this American whether he lives in a police state; it's obvious how he will answer. These measures are there to protect us from "terrorists," and "illegals," and "gang bangers"! Showing our papers doesn't make us any less free--in fact it's the price we pay for our great freedom. Just so, the Germans thought they were free.

Life was good, for Germans in the Third Reich. For 99% of them, anyway. If any chicken little should object that they were living in a police state, they could rightfully scoff. "Have you ever been taken to Berlin, or loaded on a train, or gassed?" No, of course not. "Has any relative or friend of yours experienced any of these things?" No, most likely not. "So how can you call this a police state?" Germans got up in the morning, went to work, went to the pub, came home, and went to bed. For most Germans, there was no visible sign of a police state, anywhere they looked.

I've been asked before whether I've ever been spirited away to Guantanamo, or tortured, or held without charges, or killed by a drone. I can honestly say I haven't. Nobody I know has experienced any of these things. I've been frisked, rather intimately, in airports; I've had my electronic communication monitored (as has everyone else, whether they realize it or not); I've had to get a passport so I can visit Canada or Mexico; every package I've ever ordered from China or Israel has arrived opened; all of these things are true. But that's just the price of freedom--those measures are all for my own good.

What I wonder is, if the United States were ever to become a police state, how would we know?

Salsa - My First Water-Bath Canning Experience

noreply@blogger.com (Len Budney) — Mon, 15 Oct 2012 16:01:00 +0000

Finally, canning again

I started canning in 2008. For practice, I canned a couple dozen quarts each of pinto beans (which were delicious, I must say), turkey stock, and applesauce. I bought an All American Canner model 925, used, which I've been delighted with (and also used to pressure cook whole chickens and some other things).

Back then the problem was that our kitchen was a shambles. Our house was a duplex, and the downstairs kitchen had literally no counter space apart from the foot or so on either side of the sink. Julie and I did these canning projects on folding tables, and it was pretty tough going. Thus began a project to remodel the kitchen, which is a long story for another day. The conclusion of that story is that we had a contractor finish the kitchen remodel for us, this past April, and the kitchen is now gorgeous. Every available foot of wall has cabinets and countertops. Ironically we still wish for more space, but we're much better off now than we were in 2008. I wish we'd done this four years ago.

Since May I've been meaning to resume canning, which was after all the original motivation for finally doing something about that kitchen. Finally, this weekend, we did.

Salsa?

Yes, salsa. We actually go through a tremendous amount of it. We use it for chips, but also over rice (Spanish rice in minutes!), on baked potatoes, on scrambled eggs (or in our case, Egg Beaters™), etc. I'm vaguely dissatisfied with the stuff we buy, so making some might be the first step toward the perfect salsa, and it sounded easy enough to make. I was wrong about that.

So on Saturday we stopped at a nearby farm stand and bought a crate of tomatoes (I'm guessing it was about a half-bushel), some onions, jalapeños, garlic, and green peppers. Then I took a ten mile bike ride to Walmart for some lemon juice, tomato paste, and cilantro.

Sunday evening (after another 17-mile bike ride with my son), Julie and I optimistically set to work at almost 9:00 PM.

Prep Work

Prepping the tomatoes wasn't hard work, but there was a lot of it. Before starting, I put 24 pint jars into the dishwasher for a quick wash and heated dry--the jars need to be hot. I also put a sauce pan full of jar lids into the oven at 200°f, to keep them hot; it seemed like less work than simmering them on the stove, since they need to be watched to prevent boiling. I put about 4 gallons of water in the All American™ canner, and set it to boil (which takes forever!). Then I put a 12-quart stock pot on the next burner with about a gallon of water. When the stock pot was boiling, I cut an X in the bottom of four tomatoes at a time and dropped them in the pot for 1 minute. When the timer expired, I switched them into a bowl of ice water, and Julie peeled and cored them. It took perhaps a half hour for this operation.

When the tomatoes were all peeled, Julie minced about 8 cloves of garlic and 12 jalapeños (without seeds!) in a little food processor, followed by 6 cups of onions and 2-3 green peppers. I removed the seeds and jelly from the tomatoes. At first I cut each one in half, and gently squeezed each half into a strainer; before long I tired of that, and found by experiment that it works nearly as well if you simply squeeze the whole tomato. The seeds and juice come out the hole where the core was. That took a solid half-hour as well.

When the tomatoes were seeded, I ran them in the big food processor until they looked like salsa to me. I like salsa on the less chunky side, and Julie likes it more, so I tried to split the difference there. The crate of tomatoes came to almost exactly 6 quarts. Then into the (washed out) 12-quart stock pot went:

6 quarts of tomatoes (processed)
6 cups of onions (minced)
12 jalapeños (seeded and minced)
2 green peppers (seeded and minced)
8 cloves garlic (minced fine)
24-oz can diced tomatoes
24-oz can puréed tomatoes
4 cups bottled lemon juice (natural strength)
2 tbs salt
2 tbs sugar
2 tbs ground cumin
1 tbs black pepper
1/2 cup cilantro leaves, minced

It took a good while to bring that to a boil, and then we simmered it for 30 minutes, stirring occasionally.

Processing

Once the salsa was cooked, we set up an assembly line. We put pot holders on one end of the countertop, about 4' from the stove, and set the pot of salsa on that. Next to that we set the pan full of lids and the lid lifter; next to that the bands (which came with the jars); then next to the stove the jar lifter. The water in the canner was gently boiling.

The process was pretty easy from that point. Julie took a jar from the dishwasher, filled it with salsa, leaving 1/2" head space, and wiped the rim of the jar with a damp cloth. I fished out a lid with the magnet, put on a band, and lifted the jar into the canner.

As we worked, it became clear that a couple things weren't working out as I'd planned. The canner is supposed to hold 19 pint jars. However, (1) that depends on the size of the jar, and (2) that refers to pressure canning, not water-bath. The wide-mouth Ball™ jars we used only fit 8 to a layer, or 16 total. And the second layer of jars comes near the top of the canner: when pressure canning, you only need a few inches of water in the bottom, and the work is actually done by steam that fills the canner; when water-bath canning, you're supposed to cover the jars to a depth of a couple inches. So technically the canner is only supposed to process one layer of jars when water-bath canning. And we ended up filling not 16 jars, but 23 2/3.

We plowed ahead anyway: we put two layers in the canner, with less than 1/2" water above the top, and gently set the lid. We had to scoop out a little to prevent it boiling over. Then we got out the water-bath canner and used it for the last seven jars. Getting both to a boil took a while--pro tip: on a normal kitchen stove, a giant canner will never get to a rolling boil with the lid off. Once both were boiling, we set a timer for 20 minutes. After 20 minutes in the water bath, I set another timer (Julie having gone to bed at this pint, since it was nearly 1:00 AM) for 15 minutes and turned off the heat. When they'd cooled just a little, I pulled them out with the jar lifter and set them on towels to cool and seal.

The Results

All the jars sealed, so that's great. We haven't tasted the canned salsa yet. The extra 2/3 jar tasted awesome--I had some on my eggs this morning--but it didn't go through the water bath, so it had about 1/2 hour less cooking time. The processed jars will no doubt taste different. I'd expect the cilantro flavor to be less vibrant in the processed salsa. So the jury is still out, but it looks very promising.

Toodledo and If This Then That

noreply@blogger.com (Len Budney) — Sat, 22 Sep 2012 23:01:00 +0000

Toodledo and If This Then That

Two great web apps that taste great together.

There are a handful of tools out that that bowl me over with their possibilities. They seem to have infinite potential, even if I can't think of just what to do with them right now. One of them is Don Libes's expect programming language. Another is the web app If This, Then That, or IFTTT. Here's how I just set up a "recipe" on IFTTT to create to-do items by taking a voice memo on my cellphone.

What is IFTTT? It does what the name says: it's a web service that arranges for "that" to happen whenever "this" happens. I have about a dozen and a half of these set up, so when I post this blog entry, an IFTTT action will tweet a link to it from my twitter account, and another will post a link to it on my Facebook page. When I upload a picture to Facebook, a copy will be saved to my Flickr account. When I mark something with a star in Google Reader, that article will be saved in Instapaper for me to read offline later. If you browse their recipes, you'll get the idea quickly. See what I mean about infinite possibilities?

So what do I want to do with all that infinite power? Well, one thing I want pretty badly is to do useful things with my iPhone 4, like create to-do items in Toodledo by voice. The iPhone 4 is a museum piece--which is why I linked Wikipedia instead of Apple--and it doesn't support voice commands. For that I'd need an iPhone 5 or at least a 4s. I used to have a cool voice-command app called Siri, but it was mysteriously pulled from the app store shortly before they announced that the iPhone 4s would talk to you in a feminine voice and go by the name of "Siri." Hmmm.

Since then I've looked at any app that promises voice command. Dragon is pretty good, but it's really nothing more than a notepad that takes dictation. Vlingo isn't too bad, but I've found it frustratingly hard to use. Enter Voice Assistant. It has pretty accurate voice recognition--but ironically, I found it the most useless of all. It's a "do one thing" app. If you tell it in the preferences that you want to send text messages, then that's all it can do. If you tell it you want to send emails, then that's all it can do. It can only do one thing. How incredibly, utterly useless!

But suddenly I find myself wanting to do only one thing. I just want to talk into my phone, and create a to-do item. How on earth is that so hard? (And if you're going to tell me to bite the bullet and buy an iPhone 5, I can only say to you, "Shut up.") I used to use Jott, until they wanted me to start paying monthly for it. I tried to use Google Voice, but I could never get its "straight to voicemail" feature to work--they're convinced that when I call from my cell, I want to listen to my voice mails rather than leave one. Which somehow makes the single-minded stupidity of Voice Assistant attractive. If I tell it to send a text message, then by golly that's exactly what it will do.

But where to send the text? Toodledo doesn't accept text messages. I subscribed to the Pro service because it lets me create to-dos by sending an email message, but email is all it can do. What I need is some way to set things up so that If I send a text message, Then an email is sent to Toodledo...

And lo and behold, I know of just such a service. Five minutes at IFTTT, and I have just what I need. Whenever I send a text message to Toodledo from my cell phone, they will use it as the subject line of an email from my Gmail account to my secret Toodledo email address, which Toodledo will funnel into my inbox. I've shared the recipe with the public under the name "Text messages -> Toodledo."

Using it has a few moving parts, of course:

First, sign up with Toodledo and subscribe to "Pro Plus" for $30/year.
If you don't already have one, get a gmail account.
Get yourself an iPhone and install Voice Assistant.
Then, register with IFTTT, activating the SMS and GMail channels.
Find the Text Messages -> Toodledo recipe and click "Use Recipe."
Enter your secret Toodledo email address as the email "To" address, and save.
Note the phone number the recipe gives you for sending your text messages to.
On your iPhone, create a contact for "Toodledo," using your secret email address and the SMS phone number from IFTTT.
In Voice Assistant on your iPhone, enable "Fast Access - SMS & iMessage," and choose the Toodledo contact as your "Favorite Sms & iMessage" preference.

That's it. Now whenever you dictate something in Voice Assistant, it will automatically pop up as a voice message. Tap "send," and it will go to IFTTT, who will send an email to Toodledo, who will turn that into a to-do item. Somewhere in this chain of events, I'm sure a pin pops a balloon, which scares a cat, which jumps onto a sleeping man's head, who rolls down a flight of stairs, landing with his nose on the RETURN key.

Connecting OS X Leopard to a Cisco VPN

noreply@blogger.com (Len Budney) — Fri, 28 Sep 2007 16:36:00 +0000

That nastiest part of being an early adopter is that we’re forced either to to without creature comforts, or to hack up substitutes. Now that Leopard is fairly stable (as of pre-release 9a559), some of us have started using it full-time--but the first bump in the road is that our Cisco VPN client doesn’t work, and we can’t connect to our offices to work from home.

Luckily, there is a solution: vpnc. Vpnc is a command-line client for Cisco’s VPN concentrators, and it works on Linux, every flavor of UNIX, and most importantly, OS X including Leopard. It’s simple to get up and running:

1. Install XCode Tools from the OS X install DVD

You’re going to be compiling some software by hand, so you need the compiler and other utilities included in XCode Tools. Pop in your DVD and look under “Optional Installs” for the XCode Tools package. Double-click it and follow your nose.

2. Install the TUN/TAP kernel extensions

Download the tun/tap drivers for OS X. The version for Tiger (OS X 10.4) works fine with Leopard (OS X 10.5) as well. Download the source package: inside it are the folders tun.kext and tap.kext, containing the pre-compiled kernel extensions. In a terminal window, locate those folders and install them as follows:

        # sudo mv ./PATH/tun.kext /Library/Extensions
        # sudo mv ./PATH/tap.kext /Library/Extensions
        # sudo chown -R root:wheel /Library/Extensions/{tun,tap}.kext

Then test them with the following commands:

        # sudo kextload /Library/Extensions/{tun,tap}.kext
        kextload: /Library/Extensions/tun.kext loaded successfully
        kextload: /Library/Extensions/tap.kext loaded successfully

        # sudo kextunload /Library/Extensions/{tun,tap}.kext
        kextunload: unload kext /Library/Extensions/tun.kext succeeded
        kextunload: unload kext /Library/Extensions/tap.kext succeeded

3. Install libgpg-error and libgcrypt

The latest version of each should be fine; that’s what I’m using. You have to install them in the order listed: libgcrypt uses libgpg-error and won’t build without it. Download and unpack the tarball for each, then in a terminal window do the following:

        # cd libgpg-error-version
        # ./configure
        # make
        # sudo make install

        # cd libgcrypt-version
        # ./configure
        # make
        # sudo make install

When configuring libgcrypt for an Intel Mac, you’ll need to say “./configure --disable-asm” or else the library will build and install fine, but programs using it will not work. You can leave that option off for PPC Macs.

4. Install vpnc

Download the vpnc source code and unpack it in a convenient location. In a terminal window, build and install it:

        # cd vpnc-version
        # make
        # sudo make install

If you installed the above libraries correctly, vpnc should build and install without errors. That’s it! You’re ready to be productive again! That is, as soon as you...

5. Configure vpnc

The vpnc distribution comes with a template configuration file, vpnc.conf, which looks like this:

        IPSec gateway <gateway>
        IPSec ID <group-id>
        IPSec secret <group-psk>
        IKE Authmode hybrid
        Xauth username <username>
        Xauth password <password>

If your VPN uses group authentication and XAuth, you can fill in the blanks in this file and you’re set to go. You may need to change the IKE Authmode option from “hybrid” to “psk.” Put your username and password in the XAuth lines, and get the gateway IP address and group ID from your Cisco VPN configuration.

The IPSec secret is your group password. If you don’t know it, you can look in:

        /etc/CiscoVPNClient/Profiles/VPN-NAME.pcf

There you’ll find the encrypted group password. Copy and paste that into this web page to recover the original password, and put that in your vpnc.conf.

Save the resulting file in /etc/vpnc/vpnc.conf

5. Run vpnc

Running vpnc conveniently involves several steps, so it’s best to put it in a shell script like the following. I named mine, imaginatively enough, “startvpn.”

#!/bin/sh

# Remember the default gateway
GATEWAY=$( route get default | egrep gateway | awk '{print $2}' )

# Reload the kernel modules
kextunload /Library/Extensions/tun.kext
kextunload /Library/Extensions/tap.kext
kextload /Library/Extensions/tun.kext
kextload /Library/Extensions/tap.kext

/usr/local/sbin/vpnc /etc/vpnc/vpnc.conf

# Switch the default gateway back
/sbin/route delete default
/sbin/route add default $GATEWAY

This script first reloads the kernel modules, then starts the VPN, and finally resets your default gateway so that normal traffic will not go through the gateway. If you want everything to go through the VPN, you can change the script accordingly. Note that this script is Darwin-specific; you’ll need to change it slightly to make it work on Linux or some other *NIX flavor.

You should probably also create a “stopvpn” script like this:

#!/bin/sh

# Stop the vpn
/usr/local/sbin/vpnc-disconnect

# Unload the kernel modules
kextunload /Library/Extensions/tun.kext
kextunload /Library/Extensions/tap.kext

The unloading and reloading of kernel modules is just for good hygiene; well-written kernel modules shouldn’t need reloading, but it can help clear leftover state from your last connection and avoid potential problems. TIP: this is very useful for Cisco’s vpn client.

Put the two scripts somewhere in your path. Then, whenever you need to connect to your VPN, just open a terminal and say “sudo startvpn,” followed by “sudo stopvpn” when you’re done.

Happy telecommuting!

Back from Bible School

noreply@blogger.com (Len Budney) — Tue, 26 Jul 2005 12:37:00 +0000

It's been about three weeks since I've written to the blog, but it's been a busy three weeks. No, losing Buttons hasn't driven me over the edge, though my son is still trying to figure out when Buttons is coming home to us. Sigh.

The biggest thing to happen since early July is the new version of iTunes, which allows users to subscribe to podcasts. I've been aware of podcasting for quite some time, but haven't actually followed any because it didn't seem worth the trouble. With the new iTunes, you can subscribe to a podcast and automatically get the latest one. You can also keep your podcasts synchronized with your iPod, which was a real lifesaver for me during last week's vacation. My current subscriptions are the Marty Roberts show, produced in Bethel, Israel, and the podcast from the von Mises institute. The former is an awesome news program, focusing on current events in Israel. The latter is a motley collection of lectures on Austrian economics--a version of classical economics that I strongly favor. Austrians tend to be libertarians, so there's a mix of libertarian commentary as well.

Naturally, I've started my own podcast. Lest you think I'm (only) jumping on the bandwagon, I should say that I've been planning to do it for some time--it's just the lure of publication on ITMS that finally clinched my resolve. So far the "Len Budney Show" is partly audio blog, partly comment on events in Israel, but I don't intend to be strictly an audio blog. Current events and issues will be a big part of it, but comment on various Bible topics as well. What's tricky is that I'm still learning how to do the podcast thing; I was never a college DJ. Filling the air and keeping to defined time segments takes a bit of practice. Another challenge is balancing the content, because I don't plan on making a podcast with only Bible believers as the target audience. My idea is to keep things relevant, understandable, and at least a little interesting to non-believers. That's a tricky order, so I'm feeling my way along there. So far three shows are "in the can".

Last week I attended the New England Christadelphian Bible School, in its new location at the Ascutney Mountain Ski Resort near Ascutney Vermont. It was an awesome week--the classes were great, the food was good, and the scenery was beautiful. From a technical standpoint it was a visit to the middle ages, because there was no cell coverage, no Internet, no nothing. That was tough. I did use my laptop extensively, but a laptop without Internet is basically lobotomized. I used it mostly to edit photos of the Bible School, and to take notes on the classes.

I couldn't check my email or download the latest podcasts, since there was no Internet. Luckily I had a full collection of old podcasts to listen to. Every morning at 6:00 I took a three-mile walk through the resort, and the fully-loaded iPod kept me company. Schweet!

Right now I'm on the bus back to work. After eleven days away, I'm looking forward to getting back into it! There's a daunting pile of stuff to get through my first day back, judging by the emails (the deluge of emails) I got on returning home. It should be a great week. I like having a nice full (but not overful!) pipeline.

Goodbye, Buttons

noreply@blogger.com (Len Budney) — Mon, 04 Jul 2005 03:48:00 +0000

My cocker spaniel Buttons has a whiny sort of bark, which I admit is annoying. I spent three hours building her a kennel yesterday, because my wife is at Bible school with our five-year-old for the week. Since I catch the bus to work at 7:30 in the morning, and get home about 6:30 in the evening, the dog was going to have to stay outside. Eleven hours inside was a recipe for damaged carpets.

Buttons's first introduction to the kennel came last night. I put her inside and, to see what she would do. The officer was very nice, and said that they had received four phone calls complaining that the dog had barked continuously. I explained the situation, and asked if I'd get in trouble if I tried her again in the kennel to see if she settled down a bit. He replied that the worst that could happen was that the neighbors would complain again, and we'd have another conversation. Nice man.

So Sunday morning about 9:00, before church, I put Buttons back into her kennel. She didn't make a peep at that time, nor for the next fifteen minutes or so that I observed her from behind the kitchen curtain. I left for church. Afterward, my dad and I drove a block away in his car, and watched her for a bit. She was laying quietly in her kennel, not making a sound. We drove on to lunch.

Perhaps a half hour after returning home, the police car arrived. I went out on the front step and hollered, "Howdy!" He said "Hello," in that authoritative voice that cops like to use. I said, "Come on inside!" He replied, "I'm actually busy, and have no time for you. But," he added in an angry yet commanding tone, "your noisy dog problems are over! We have a statute in this town! Here's your copy of the statute and your citation!" He handed me a copy of the statute, and drove off.

Inside, I told my dad that there was no answer but to return her to the pound. In a touching show of heart, he offered to do the evil deed for me. I agreed to stay home and tear down the kennel, in hopes of returning it to Home Depot. He put a leash on her and led her off.

It's nighttime now, and the house is very quiet. Buttons's crate is still in my son's room, pillow inside and door ajar. Her leash is still hanging on the coat hook by the door. I dread my son's return from Bible school, to hear what happened to her. The house is very quiet, and I'm very alone.

YAPC 2005 Day 3

noreply@blogger.com (Len Budney) — Thu, 30 Jun 2005 14:30:00 +0000

As before, these are my raw notes on the talks I attended at YAPC, day three. Perhaps tomorrow I'll summarize YAPC in a readable, pithy little journal entry.

Where did My Memory Go?

A useful tool for profiling memory use is Devel::Size, which offers both size() and total_size() methods. One does, and one does not, chase references to include their size in the total. If you hand it a reference, it knows to start "one level down" in reporting. It also knows enough not to follow circular references forever. Presenter Dan Sugalski proceeded to demonstrate the toolkit by finding out how large some scalars, arrays and hashes are. If you want to know, this is left as an exercise for the reader.

One note: "foreach (<FILE>)" uses more memory than "while (<FILE>)". Note that assigning a filehandle read to a scalar causes the entire file to be slurped into memory temporarily, so don't do that. (Double check that I caught the scenario correctly.)

Concerning garbage collection, recall that file-scoped lexicals are basically never cleaned up. The GC clears variables when they pass out of scope. If you have something very large, you should undef it using the undef function, not by assigning undef to the variable. If you assign an empty string to a scalar, for example, the storage used by that string is not cleared, in case it's needed. On the other hand, if your variable is going to end up big again, you might want to keep it around without deallocating it--profile, don't speculate. Generally, it's a pain to undef things, but you really should use it when your structure is hogging lots of memory.

Watch out for circular references, since things are only garbage collected when the reference count drops to zero. Either break the reference chain manually, or use weak references. Ise Scalar::Utils to make weak references with the weaken() method. Do note that perl will immediately garbage collect a structure if every reference to it is weak.

Also note that every version of Perl leaks memory. At least, you should use the latest version. Before 5.8, closures leaked. Parameters passed to new threads used to leak. Modifying @_ resulted in leaks before 5.6. Before 5.8.6, lots of ithread shared variables leaked.

The following will determine how much memory is being used by Perl in total.

        $Devel::Size::warn = 0;
        $size = total_size(*::);

You can also use Devel::LeakTrace to find some cases of unfreed variables. It tends to be whiny about globals, which makes it tricky to find the real leaks. It also slows runtime down considerably, so you should only use it in debugging.

Lazy Test Development

Joe McMahon promises to tell us about not only lazy test development, but also the necessary evils incurred in doing that. A common situation is stepping through the debugger to locate a problem, which is also a good time to think about creating a test. Joe created a module, Devel::TestEmbed, that pulls Test::More into the debugger, so you can create tests while debugging. An additional method allows you to save the tests when you're happy.

Building the module involved fiddling with the debugger, which isn't easy to change. It's about nine KLOC. Patching the debugger implies ongoing maintenance. Fortunately, the debugger offers an external interface that lets us write extensions without touching the debugger itself. There are some resources:

        * A .perldb file, included with a "do" into the debugger.
        * afterinit() is called right before the debugger prompt is first printed.
        * watchfunction() lives right inside the debugger's command loop, and is called before each prompt is printed.
        * @DB::typeahead allows you to stuff commands into the buffer
        * @DB::hist lets you look at prior commands.
        * Debugger's eval behavior can also be exploited: unrecognized commands are evaled.

Putting these together, a .perldb module is written that defines watchfunction() and afterinit(), and sets a magical $DB::trace to enable the watchfunction. The afterinit() stacks the "use Test::More qw(no_plan)" into the command buffer, so you don't have to type it. This was necessary to get the Test::More methods into the current namespace--if it were in the .perldb, it would import test methods into its namespace. The watchfunction dynamically imports tdump() into the current namespace in the program being debugged (so it follows you no matter where you are in the program). That's all watchfunction can do, because it runs outside the debugger's command loop.

Portable Perl - how to write code that will work everywhere

Ivor Williams started by mentioning some common misconceptions: although Perl is portable, a perl app may not be. Even if your app doesn't use XS, it may not be portable. At minimum, a motivation for writing portable Perl is that CPAN modules should be written portably. Exceptions usually have their own namespace, such as Win32::.

        * Be lazy--use existing portable modules whenever possible
        * Modularize--make plugins that wrap OS-specific stuff you can't avoid
        * Follow the rules in perldoc and perlport (on which this talk is based)

Filesystem Issues

The obvious portability issue in Perl is filenames. Luckily, you can completely ignore this, because POSIX paths work on Windows and VMS. The only problem with this is that there's no provision for a "volume" or "device" specifier in a path. There are also variations in allowed character sets. There is also the issue of case sensitivity.

The alternative to POSIX is to use native syntax. $^0 will tell you the OS name, so you can do what you must. But you can use the File::Spec module that handles this for you. This is OO, but you can also use File::Spec::Functions to import functions into the namespace.

Other issues include file permissions, which vary per OS, and symbolic/hard links, which are supported differently or not at all on some platforms.

Specifically in VMS, files are stored according to their version. That's why some modules say "while (unlink 'Foo')" for this reason.

Specifically on the Mac, files have resource forks. Ivor is too chicken to talk about them any further.

Invoking the Shell

Just don't do it. Commands vary between platforms, so invoking shell commands won't work portably. Shell globs will also be handled differently per OS. Environment variables can't be relied on either, such as HOME, TERM, SHELL, USER, etc. Even PATH isn't always set.

User Interaction

A script might be started with file descriptors redirected. If you need to interact with the user, you can't count on STDIN, STDOUT and STDERR. Reading from "/dev/tty" is very not portable. There's a better way specified in perlfaq 8. You can use Term::ReadKey for this purpose, though it doesn't successfully disable echo on Windows. A combination of Term::ReadKey and Term::ReadLine can be used to do the trick. Note that Term::ReadLine is a wrapper around either Term::ReadLine::Gnu or Term::ReadLine::Perl. The latter is included in the "CPAN bundle" that the cpan command installs for you.

Communications

Sharing files between machines with possibly different architectures, or communicating over the network, present portability challenges. Complying with some standard is helpful. Line-ending conventions are one example of this. Perl translates "\n" to be correct for the platform on which the script is running, which may not be the convention of the other endpoint.

Sadly you should use binmode for anything that isn't known to be an ASCII file, for portability. It matters on some platforms (though not on UNIX). This will also affect character counts depending on line conventions and applicable character set.

Endianness is an issue as well. Pack and unpack have a "network standard" format, specified with 'n' and 'N', which should be used.

Multitasking and Job Control

Beware of forks and threads, non-blocking I/O, etc. A portable multitasking package like POE should be used instead.

Perl Blue Magic - Creating Perl Modules and Using the CPAN

Famed comedian José Castro returns to the limelight for this talk. CPAN has over 5,000 modules, and over 2,000 active developers. There are ~200 developers with more than 5 modules.

First tip: PICK GOOD NAMES FOR YOUR MODULES! Nobody will use it if they can't find it! Here José gave a few humorous examples of useless and/or strange module names.

A module has lots of junk inside, but you don't have to make it yourself. You can use h2xs and other modules for this purpose. Just do one of these here:

        h2xs -XAn My::New::Module

It creates most of what you need, excluding a License or TODO file. There are other issues with h2xs modules. That's why José recommends Module::Starter instead:

        module-starter --module=My::New::Module --author="Me, Myself" --email="me@me.com"

You can also use ExtUtils::ModuleMaker. It prompts you through the creation process. You can also get help on module-authors@perl.org and modules@perl.org. But whatever you use, you should:

        * Have an idea - make sure it isn't already done
        * Document it - make sure you know how you plan to do it
        * Write tests
        * Code
        * Test
        * Ship
        * Maintain

Documentation should contain the following stuff: name; synopsis; other things generally provided in the template by the above-mentioned utilities. Make darn sure you include acknowledgements! Note that if the version number contains an underscore, CPAN marks it as a developers' version.

If you ask for a PAUSE ID, and are rejected, resubmit your application. The guy that handles the apps sometimes forgets.

Modules are "registered" when someone associated with CPAN decides they're "good". Given a choice, pick the registered modules.

Don't submit more modules than you can maintain.

Lightning Talks

This is a series of five-minute talks. The pace is supposed to be fast, so my notes will be pretty skeletal.

Five Development Tools I Can't Live Without
Casey West

        * SQL::Translator can convert schemas from one DB format to another. It can also create a diagram
        * HTTP::Server::Simple::Static provides a tiny web server without Apache
        * Devel::Cover for coverage analysis
        * podwebserver an index of the stuff you have installed
        * Perl::Tidy to neaten perl code
        * Test::Pod::Coverage
        * DBI::Shell
        * Module::Refresh refreshes changed modules in a running script
        * CPAN::Mini to provide a local copy of the latest CPAN modules

Refactoring Web Applications

        * What? Refactoring
        * When? Before adding a feature
        * Why? To simplify feature additions
        * How? WWW::Mechanize and AT

DBD::SQLLite Intro
Zachary Zebrowski

SQLLite is a small OSS DB in a single executable. It is ACID compliant and supports up to two terabytes of data. It has bindings for multiple languages and stores the entire DB in a single file. The file can be moved across platforms and still work. It's handy for rapid prototyping, local tests, etc. On the flip side, it's a single-user DB and isn't networked.

Thirty Seconds or Less
Larry something-or-other

Couldn't get co-workers to learn Wiki markup. He responded to this situation by adding even more markup to his preferred Wiki.

OpenGuides

An application for developing collaborative City guides in a wiki-like way.

Credit Cards

There are new security rules that apply to all merchants. Printed, they're an inch and a half thick. Compliance can be costly. Fines for non-compliance are also heavy.

CPAN Envy
Casey West(?)

Schwern tried to convince people to create a Javascript repository. CW decided to go ahead and create it.

Regexp::Compost
Paul Shields

A perl module that takes as its input a text and produces a list of regexes that match that (and similar) texts. It exhibits an interesting heuristic for trying to create a regex that "fuzzily" matches a sample corpus of texts.

What Has Meng Been Up To Lately?
Meng Weng Wong

Two years ago SPF was born at YAPC in FL. Microsoft decided to "embrace it and extend it to Sender ID, which will roll out in Hotmail and Outlook. On the subject of DK, Meng tried to throw FUD in the air by pointing out that PGP and S/MIME "didn't work". He's also fooling with methods of implementing "collaborative blacklists" called "Karma". From there he went on to describe something that boils down to IM2000.

Perlcast

A podcast dedicated to Perl. Go listen if you're interested.

Annotating CPAN

The idea is to permit users to annotate packages, particularly where they thing there's a gap in the documentation.

A Mail Server in Perl
Matt Sergeant

Matt maintains QPSMTPD. It reputedly handles ~1M messages per day on some hosts.The author bills it as mod_perl for email.

YAPC 2005 Day 2

noreply@blogger.com (Len Budney) — Wed, 29 Jun 2005 13:15:00 +0000

Day 2

As before, these are my raw notes from the talks attended on day 2 of the YAPC conference.

Apocalypse Now - Perl 6 is Here Today!

Part I

Autrijus Tang attempted to comfort the crowd by pointing out that the transition from Perl 4 to Perl 5 did manage to complete successfully. And by analogy, if that transition took years, we shouldn't lose hope for this one.

Reviewing the features of Perl 4, Autrijius mentioned modules, closures, references and CPAN. As of today, CPAN has more than 8,000 modules by more than 2,500 authors. It also offers a tool for automatic download, testing and installation. CPAN is the greatest thing ever to happen to Perl. However, Perl is not necessarily the greatest thing to happen to CPAN. The Perl5 syntax imposes a tax on CPAN users.

For example, sigils and references don't really behave consistently:

        $s                @a                %h
        $$s                $a[0]                $h{'!'}
        $s->foo()        :-(                :-(

One explains to a newbie that the '$' sigil indicates a singleton, whereas '@' indicates a multiplicity, and '%' indicates a multiplicity tagged with names. But when dereferencing a reference, the '$' operator doesn't indicate anything about cardinality.

As another example, there is considerable forced redundancy. The line "my $self = shift' may be as much as 10% of your code, if you write nice short subroutines like you should. The book "Higher-Order Perl" offers all sorts of fancy technology, but about 50% of it is nothing but bookkeeping.

We're used to this "language tax", because the language is useful enough to make us tolerate the cost. But in Perl 6, the tax is not necessary. In the case of sigils above, the situation resolves to:

        $s                @a                %h
        $$s
        <<crap, he switched slides too fast>>

Another savings pertains to "perl" the runtime engine, as opposed to "perl" the language. XS modules in Perl 5 are difficult to write and to maintain. Backward compatibility prevents us from cleaning up that situation. One engineer likened this situation to a game of Jenga: we have a convoluted pile of sticks, and we enhance it by piling more on top while creating holes lower down. All the guts of Perl have multiple applications because we're forced to keep drawing sticks from elsewhere in the pile.

Inventive CPAN authors began creating Perl 5 dialects, using source filters created with tools like Filter::Simple to build a "preprocessor" stage. These dialects are mutually incompatible. Source filters are guaranteed not to work together, because each expects a strange dialect as its input.

Another problem in Perl 5 is that the regex syntax imposes an arbitrary limit on what can be done. Similarly with operators and other aspects of the grammar. The Perl regex engine is not re-entrant, so modules built on them are guaranteed to be fragile.

OO and functional code unfairly handicaps golfers. Golfers always converge on line-based text processing with y// and s// as their two main operators, because the syntax becomes too verbose elsewhere in the language. Unfortunately, that affects regular programmers instead of golfers, because we always take the path of least resistance.

Fast Forward to Perl 6

Perl 6 is faster: soft, incrementally typed, with program-wide optimizations. Stronger types can be retro-fitted to a program. It's also friendlier: you can call Perl5, C, Tcl or Python libraries directly. It's also easier: common usage patterns are dramatically shortened. You can even read a one-liner with comprehension! It's stronger, because it includes support for OO, Functional and Data-driven styles. It's leaner because it offers sane semantics instead of endless workarounds (that have become entrenched idioms, of course).

Autrijus then demonstrated a perl 6 script for uploading modules to CPAN. It was written to be interpreted using pugs, and has some workarounds for perl6 weaknesses by evaling some code in a perl5 context. You can run all your perl5 code under perl6 by writing a perl6 script that pulls it in and runs it. But before you laugh, remember that the early perl5 scripts still used perl4 libraries, because there wasn't a body of perl5 libraries available. The first perl6 scripts will behave similarly.

Today the pugs interpreter cheats by linking in libperl, so of course it works. As an aside, it is also subject to perl5 garbage collection bugs as well.

Going the other way, you can imbed perl6 code in perl5 scripts by invoking the "use pugs" pragma in your perl5 code. You can turn off the perl6 behavior with the "no pugs" pragma. That works today (but, not very well). Sicne it uses Inline::Pugs and source filters, it won't play nicely with source filters. It also invokes a pugs process and shuffles code back and forth to it, so you can't use it with things like DBI. Don't use it in production today. Folks are trying to fix it up so it works more reliably--stay tuned for the second part of the talk. You can get the pugs stuff at http://www.pugscode.org/.

In response to a question, Autrijus replied that he has no idea when the perl6 camel book will come out. There are two books on the market already--the only problem being that 50% of the material is outdated, and you don't know which 50%. The questioner seemed a bit frustrated and kept demanding some hint when perl6 will be production quality. He turned the question around beautifully by suggesting that the questioner could do a great deal to hasten the day.

Pugs was started on Feb 1, so it's only five months old. It started as an exercise based on "Types and Programming Languages", which is another recommendable book, along with "Higher-Order Perl". The exercise at the end of the book said, "Implement a small language that you know of." (There was general laughter at this point.) The first cut took only two days, because it was written in Haskell. Haskell is optimized for compiler writing. As an aside, Autrijus commented that Perl 5 closures leak memory horribly. Switching to lazy references resulted in random seg-faults. These problems are what drove him to use Haskell.

Autrijus summarized the progress to date, but it was a list of test scripts and such, so I didn't write it all down. Recently, someone created a pugs-based IRC bot called evalbot, so IRC users can test evaluate perl6 commands. The most popular command seems to be 'system("rm -rf /")', but "we aren't completely mad, so that doesn't work." Haskell makes it easy to identify unsafe commands, so a safe mode was created that prevents users from doing things like "print" or "system".

Pugs has over 100 committers, mostly because Autrijus hands out committer permissions to passers by. There have been over 5,000 revisions committed. There seems to be a positive feedback cycle, because when someone commits something, they seem to commit to something. Autrijus's own contributions are falling off over time--currently, below 40% of commits. His main function is maintaining a pugs journal and praising contributors.

The "State of the Carrot" speech claimed that pugs covers 80% of Perl 6 semantics, but that's wishful thinking. To a first-order approximation, some 30% of the semantics is covered. There are 7,000 automated tests today, with another 15,000 anticipated.

Part II

If you're interested in contributing to pugs, the first rule is: to report a bug, write a test. Test.pm is really simple to use, if Autrijus does say so himself. A pretty little graph created by Test::TAP::HTMLMatrix that shows passed tests (green), failed tests (red), todos (dark green), etc. One cute aspect of this tool is that, if tests == bug reports, and tests are added to the end of a test script, then red marks at the end of the graph generally represent new bugs.

One attendee asked about the problem of submitted tests that are wrong, or that don't test what they purport to test. Autrijus replied that it isn't common, but it isn't rare either--perhaps 10% of submitted tests have some kind of problem. In the course of maintaining his journal, Autrijus reviews every patch. Others perform code reviews in the case of their work.

Current efforts in pugs concern OO. Introspection and roles are not underway yet. Once the OO features are working, work will focus on rules. Closures don't work yet.

Some benefits of Perl 6:

        * Simplicity
        * Clarity--different constructs look different, such as string eval and block eval (the latter being renamed "try").
        * Sub names are clearer--for example, several clear names replace multi-purpose "length"
        * Brevity: the dot notation saves keystrokes over the arrow notation
        * Implicit parameters are removed (such as $a and $b in sorts)
        * Operator overloading
        * Method overloading via type-based dispatch
        * Some new operators like "yada yada yada" and "defined or" ("$arg //= 3" means "$arg = 3 unless defined $arg")
        * Operator chaining (using transitivity)
        * "Hyper" operators that apply to an entire array
        * Reduction operators that collapse a list by means of an operation
        * Junctions are useful for situations in which complex conditionals are used
        * Type globs are history
        * Smart match (~~) replaces (=~) but has extra coolness like "$a ~~ any(<1, 2, 3>)" (not sure of exact syntax)
        * Exception handling is unified under $!

Some people are distressed that dot as string concatenator is replaced with the tilda. But don't worry: interpolation is so darn good, that the operator is practically obsolete. One attendee complained because he uses ".=" all the time.

Perl 6 has switch statements! They're coded using "given / when".

Problems with Pugs:

        * Can't emit compile-time errors
        * No support for warnings or strictness
        * Slow -- dispatch is 100x slower than perl5
        * <<missed the last one>>

There are also parsing problems due to the ambiguity of Perl and the difficulty of optimizing parrot assembly, so PIL, the Perl Intermediate Langauge, was invented. PIL has far fewer node types (namely 16 at the moment). The result is a sort of "diet perl 6", perl6 like with no syntactic sugar left. PIL is still under development, so it isn't finalized, but it is stable. Other languages may or may not be translatable into PIL.

Note that in the "real" perl 6, the compiler may well not be self-hosting. Among other reasons, proponents of other languages may not like haivng a compiler written in Perl. So Perl/Parot is not the same as C#/.Net. Pugs is entirely different. It wants to become self-hosting, because it's cool to be self-hosting, and it's also desirable to run perl 6 on the perl 5 vm, or to compile to C or some other backend. Self-hosting yields benefits:

        * Well-defined semantics (or it won't work)
        * Less chance of misfeatures like "my $x if 0"
        * Eliminates the low-level black box (such as XS or parrot assembly)
        * Proves that Perl 6 can handle complex tasks like compiler writing--Perl 5 was weak in this area

Status of the Perl 6 Compiler

Patrick Michaud followed up Autrijus's report on pugs with the status of the "official" compiler. Perl 6 embraces more than the Perl six language itself. Interoperability with other languages is also a high priority, which involves a runtime environment compatible with multiple languages (Parrot), a suitable suite of development tools, and a platform for code development. As Larry said, we both should and should not implement Perl 6 in Perl 6.

In short, Perl 6 isn't there yet. The specs are firming up, but still incomplete. Deficiencies in parrot are impacting the compiler now.

Parrot in Detail

What Parrot Is

Parrot is a multi-language VM intended as the interpreter for Perl 6. It started as an April fool's joke that got out of hand. VMs get you several things: platform independence; impedance matching; high-level base platform; good target for a particular class of languages. The major components are the parser, compiler, optimizer, and interpreter.

The Parser converts source code into an abstract symbol tree. The Perl 6 parser can be overridden: new tokens can be added; existing tokens can have their meaning changed; languages can be swapped out. All of this will be accomplished using Perl 6 grammars. Perl 6 grammars are immensely powerful. They're a combination of perl 5 regexes, lex and yacc.

The Compiler turns AST into bytecode. Like the parser, it's overridable in perl 6. Conceptually, it's just a fancy regex. It doesn't perform any optimizations at all. These tools help in building compilers, which is a standard task but involves a lot of work. There isn't much in the way of complexity here. Even lisp programmers won't pretend to have invented it.

The VM is a "bytecode engine" based on 32-bit words. Programs are (or at least can be) precompiled and then loaded from disk. USually no transformation at all is needed at runtime. Most opcodes can be overridden, and the bytecode loader can be overridden. Dynamic opcodes can be used for cool things like loading uncommon functions only on demand.

The VM is register based, having four sets of 32 registers: Integer, String, Float and PMC. The registers are a fast set of temporary locations--all opcodes operate on registers. There are also six stacks: one for each set of registers; one generic stack and one call stack. Stacks are segmented, but have no size limit.

The strings data type is a high-level data type, consisting of a buffer, a length field, and a set of flags. Flags cover things like character set, encoding and length in characters (rather than bytes).

The PMC type wraps the equivalent of Perl 5's variables. Tying, overloading and magic are all swept under that rug, as are arrays, hashes and scalars. All operations on PMCs use the multi-method dispatch core (MMC). This is a recent change, and simplifies vtables and other things. It improves performance, because most interesting PMCs end up using MMC anyway. All PMCs can potentially be treated as aggregate structures: vtable entries have a _keyed variant, and the vtable must decide whether the key is valid.

Objects divide into two types: reference objects and value objects. So objects may or may not be accessed by reference. This makes it possible to handle objects in the same way as low-level types.

At this point the two speakers began flying through the slides, so it became impossible to keep up for a little while.

Why Parrot?

The biggest deficiency of the JVM and the CLR is that they're designed around static code. Classes can't be changed at runtime in the JVM; existing things can't be fiddled with in the CLR; etc. The parrot runtime will support that sort of perlish flexibility. In addition, a VM permits interoperability between different scripting languages, which takes TMTOWTDI to a new level. Today there are lots of inter-compatibility shims, but they grow like n!, where a common runtime permits n^2 growth.

On the other hand, why not parrot? Why hasn't it been adopted yet? Why is the community so small? The first question is, what constitutes a user of parrot? People running parrot applications are not "parrot users", and more than someone running an applet in a browser is a "java user". The developers are the users. Current major users are Pugs, Tcl (ParTcl) and Perl 5 (Ponie). Folks that gave up on parrot often did so because their stress level was too high. They got tired of the moving target, and other things.

Parrot is a platform, which means that it lives or dies on the apps that others write for it. The project's biggest need is developers. The most important of those contributions are pugs and PGE. Another critical need is to keep the specs and design documents up to date. Another is tests: the best way to record a missing feature is to create a test that checks for it.

Parrot Grammar Engine

Patrick Michaud opened with the remark that Perl regexes have been so successful that of course they're being thrown away. For the purposes of this talk, "rules" are perl 6 regexes, and "regexes" are perl 5 regexes.

A brief overview of the rule syntax comes from "Apocalypse 5", though that document is really out of date now.

        * Capturing is still done with parens
        * Star, + and ? work the same
        * Pipes represent alternatives

On the other hand, modifiers go at the start of the expression rather than the end. The /e modifier has gone away: if you want a code block, stick one in there. The /x option is now the default. There are no more /s and /m modifiers; there are new metacharacters. The :w or :words modifier treats whitespace in the pattern as \s* or \s+. There are also new modifiers like :exhaustive, :keepall, :overlap and :perl5.

Among metacharacters, the dot now matches newlines. The ^ and $ always anchor to the start and end of the string. Double ^^ and $$ match beginnings and ends of lines. The # always introduces a comment. Whitespace is metasyntactic depending on the :w setting. Now \n matches newline in a platform independent way, and \N matches anything but (like the perl 5 dot). Now & is a conjunctive match.

Asked for an example of & in use, he replied, he couldn't give a very clear example. He did remark that ampersands can be changed as long as you like, and every item in the chain eats the same number of characters, or the match is a failure.

Although parens capture, numbering is different.

Now square brackets are non-capturing groups, instead of the ugly glyph. Enumerated character classes are <[...]> instead of [].

Curly braces are now no longer a repetition quantifier--it's an embedded closure that is called at that point in the match.

The repetition specifier is now **{...} for maximal matching and **{..}? for minimal matching.

Scalar variables in a rule expression are matched as literally, not as a sub-pattern. I.e., /$var/ matches the content of $var exactly, not $var interpreted as a pattern.

Array references match as the "or" of the elements in the list.

A hash in a pattern causes a match on the longest matching key. The value can be a closure, a sub-rule, the value 1, or else indicates failure. That's useful for building lexers that match according to the "longest matching token" rule.

Angle brackets are heavily overloaded. For starters, a pair of angle brackets whose first content character is alphabetic is interpreted as the name of a capturing subrule. Preceding that character with ? makes it a non-capturing version. A leading ! indicates a negative match. Enumerated character classes are enclosed by <[...]>. Unescaped hyphens are forbidden, because hyphens are not used to indicate a range--you should use .. instead. A negated character class is given by <-[..]>. Plus/minus characters are used to combine subrules and character classes.

To interpolate a string into a rule, use $var. This eliminates escaping problems, among other things.

Double quotes are used to interpolate into a literal match, whatever the heck that means exactly.

Colons are used to control back-tracking behavior. A single colon forbids the rule engine to backtrack past the colon. Backtracking over a double colon causes the current set of alternations to fail. Backtracking over a triple colon causes the entire rule (or subrule) to fail. Backtracking over <commit> causes the entire match to fail (even if it's located within a rule). The <cut> assertion is like <commit>, but also deletes the matched portion of the string.

Capturing and Subrules

None of this stuff is in synopsis 5, which wasn't clear about how capturing works. It's something like this:

Every invocation of a rule returns a "match" object, which goes into a lexically scoped $/ (instead of perl 5's $0). The boolean value of $/ is true if the match was successful, otherwise false. The string value of $/ is the substring of the pattern matched. The array value of $/ contains the matches for subpatterns in parens. These can also be accessed as $0, $1, etc.

When performing a match, any capturing subpattern generates its own match object, which is stuck in the appropriate place in the parent rule's match object. One consequence is that we can no longer count parens to determine the location of the match object, because the match objects are arranged in a tree. Non-capturing patterns don't impose a capturing scope, so they don't force branching in a tree. But what about quantifiers?

When a pattern is quantified with + or * (but not ?), it produces an array of match objects--one for each match that took place. This is true regardless of the number of matches that occurred--the list can be empty or a singleton. This makes for all sorts of interesting weirdness when you factor non-capturing patterns into the mix:

        / [ \w+ (\s+) ]* / yields:
                $/[0]                An array of match objects
                $/[0][0]        Whitespace of first iteration
                $/[0][2]        Whitespace of second iteration, etc.

Subrules look just like subpatterns, but they capture to a match object's hash with the name of the subrule as the key. So in the pattern /<digit>/, the match is stuck into $/<digit> or $/{digit}. So I gather that wedges can be used for subscripting a hash now. Interesting. (In response to my question, Pat stated that it's "basically a qw".) If the same rule is used more than once, the matches are gathered into an array keyed by the rule name. Sets of named rules can be combined easily to build parsers. Like that ain't bleedin' obvious, since $/ is a bleedin' parse tree!

Each call to a rule generates a coroutine. A coroutine is a subroutine that returns control to the caller, but can be restarted where it left off with its state intact.

Currently the PGE expression parser is a recursive descent parser with thirteen node types (at the moment). The most complicated part of the parser is the handling of groups and subrules.

Using PGE

PGE builids as part of parrot. To run it, you want to load the PGE module and use p6rule. He went past quickly with the screen, so I'll need to check the details online.

A grammar is any class derived from PGE::Rule that contains rule methods. Thus one can create a new grammar in a straightforward way. Subrules, on the other hand, aren't necessarily rules. Any subroutine that returns a Match PMC with some appropriate attributes can be used as a subrule. This can be used as a path to creating parsers that don't operate by recursive descent, or at least don't use it for particular subsets of the language.

YAPC 2005 Day One

noreply@blogger.com (Len Budney) — Tue, 28 Jun 2005 03:35:00 +0000

This week I'm attending the North American YAPC (Yet Another Perl Conference) in Toronto. This is my first YAPC, since I didn't make it to Buffalo last year.

It's an interesting display of organizational prowess, so far. Last night the schedule said we could register between 22:00 and 23:00, but when we arrived there were no registration personnel to be found. The conference organizers present had no keys to the room with the nametags and t-shirts. The next morning, when we returned to register, one of the staffers put out a call for a video camera to record the proceedings (or at least the keynote).

We're now into the "opening ceremonies", scheduled for 9:00 but beginning at 9:30. Glad it's not me trying to organize this thing--I'd be frazzled silly.

Keynote: Larry Wall

Larry opened his remarks with a picture of the Golden Gate Bridge, and described his talk as "bridges and other things". His focus was on the idea of building communities, particularly of course the Perl community. He suggested that the right questions for OSS authors to ask are:

        * Who will naturally be interested in my project?
        * Who are we accidentally/purposely excluding from our project?
        * Who should lead/follow/contribute?

        * What is the goal of our community?
        * What can people contribute?
        * What are the community's rules and structure?
        * What's in it for the volunteers?

        * Where will the community meet in cyber/physical space?
        * Where can sub-communities form, either by design or spontaneously?

        * When is it too soon to form a community?
        * When does the community reach a "tipping point"?
        * When is it time to form sub-communities?
        * When is the right time to fork?
        * When are we done?

        * Why do we really want a community?
        * Why do people join and leave the community?
        * Why do people fight and stop fighting?

        * How do we do it?

On the question of when to form a community, Larry remarked that in the first days of Perl, users proposed that Larry start a Perl newsgroup. He resisted this request for about a year, because he wanted Perl users to infest the shell-users' newsgroups. As a result, Perl users promoted Perl by injecting Perl-ish solutions in addition to shell-ish ones.

Concerning the question of our real motivations for starting a community, Larry remarked that the desire for a large pool of free labor isn't a very good motivation for community building.

Waxing philosophical, Larry invoked the idea of "tensegrity", or "tensional integrity". The idea is that a stable structure results from balancing the forces that "pull" and the forces that "push". He accompanied this with several pretty pictures involving rods and rubber bands. By contrast, he suggested that the "geek" community resembles a big pile of rocks (geeks)--disorganized, formless, and without opposing forces (each member autistic to one degree or other). The linux community might be represented as a few stone pillars (distributions) around a beach, with Linus at the top, and where of course the users are dirt. A militaristic model would be a single tall tower--stratified, in which pecking order is the foremost consideration.

A more dynamic community exhibiting "tensegrity" involves both pushers and pullers, and requires us to grapple with seeming contradictions. The result of such a dynamic is "larger structures that don't fall down". Among the "contradictions" that must be reconciled to build a community are:

        1. People are naturally good / bad.
        2. People love / hate new ideas.
        3. People love / hate outsiders.
        4. People should all be alike / different.
        5. People should / shouldn't be in charge of others.
        6. It should be easy / hard to break into the community.
        7. We should / shouldn't try hard to keep people in.
        8. Specialization is good / bad.
        9. People volunteer for altruistic / selfish reasons.
        10. We do / don't need a benevolent dictator.
        11. Larry Wall is important / unimportant. Or more to the point, he's a genius / idiot.
        12. Modernism is good / bad.

From there he rambled off into a discussion of "natural communities" from a darwinian perspective, invoking notions like a "large gene pool", "speciation", "range of variation", etc. He suggested that part of what's keeping Perl 6 is the effort to ensure that it's modeled on natural communities that thrive, rather than those that go extinct. For example, the Perl 5 community is seen by Larry as neither sufficiently unified nor sufficiently diverse.

        A community needs to share a set of core values, but also to allow honest differences on the periphery.

A technological solution to these set of problems both is and isn't possible. On the positive side, Perl 6 will have a finer-grained extension mechanism. Among other things, scoping will be clarified and cleaned up. A CPAN-like repository can provide a gene pool. We can separate combatants, if we can convince them to join separate mailing lists. Technologically, we can at least provide enough mailing lists for hostile tribes to coexist peaceably.

On the negative side, people are still basically irrational. One way to mitigate this is to look for cheerleading opportunities. We can try to tolerate differences within the community, but it ain't easy. We want to encourage and discourage cultism. We want to "have fun", but we can't always. Sometimes building a community involves submitting to crucifixion.

Allison Randal: The State of the Carrot

A "carrot" is what you get when you cross a camel with a parrot. Allison read a parody based on "The Hunting of the Snark".

Over the past year Perl 5 has experienced a bunch of fixes and optimizations. More interestingly, reverse sort no longer uses an intermediate list, which improves performance. Some setuidperl exploits have been fixed. PLEASE stop using setuidperl. Another -Dusersitecustomize option permits customization of @INC using a site customization script.

On the Perl 6 front, there are many pieces.

At the bottom is Parrot, the VM for Perl. There was the parrot 0.1.1 release last october, including incremental garbage collection and a "make install" target. Parrot has moved to subversion in version 0.2.0. Current version is 0.2.1.

Next is Ponie, the Perl 5 compatibility layer. Snapshot 4 was released today. Ponie work has benefited Perl 5 as well, because improvements made in Ponie are being back-ported to Perl 5.

Pugs is a Perl 6 prototype. Some 80-90% of the Perl 6 semantics have been implemented already. It's currently written in Haskell, but ultimately it should be written in Perl 6.

Allison also reported some things about the funding of the Perl foundation, Perl Mongers and Perl Monks. There's a new Perl logo (a pearl onion) that can be used without legal encumbrance, because O'Reilly owns the camel.

Session 1: The Tester's Toolkit

Pete Krawczyk opened with the usual ra-ra in favor of automated regression testing: tests supplement documentation; they facilitate bug reports; reduce maintenance costs, etc.

A "test" is a perl program with extra modules, that reports actual versus expected results. Tests are usually invoked via a "test" target in the makefile. Another useful command, as of Perl 5.8.3, is "prove", which runs a directory of tests. A script named t/TEST is also sometimes used. But since a test is a Perl script, you can run it by hand (but without the summary features provided by the test harness). Example code for this talk is found in the Acme::PETEK::Testkit module.

Considerations when writing tests:

1. Make sure most important code is tested. People don't actually test every branch of code, and ROI diminishes as you jump through hoops trying to achieve complete coverage. Conversely, from zero tests, every added test is an improvement.
2. Test scripts should have a "plan".
3. Don't print to STDOUT! Use diag() instead. Testing scripts that print to stdout may involve extra work to capture output.
4. Test for failure as well as success.
5. Give tests a description. If you don't you'll be stuck figuring out which one was "test 50046".

Moving on to testing specifics, Pete introduced Test::More by showing some examples of the standard tests, use_ok(), is(), is_deeply(), cmp_ok(), can_ok(), etc. Tests can be put in a "SKIP" or a "TODO" block, and Test::More will handle them gracefully.

The prove script handles invocation of tests in a folder, using Test::Harness, simplifying the relevant Perl one-liner. It also has extra features such as "verbose" and "shuffle" modes. It is intended as a development tool, to run tests with some granularity during debug/test cycles.

He went on to talk about Test::Inline, and I didn't pay close attention to that section. Including tests within the script to be tested is a matter of taste, and my taste doesn't run that way. I also skipped the Test::Legacy section. It's intended purely to migrate tests written with Test.pm to the new testing framework. Likewise, I already know about Test::POD.

For those who shy away from complex tests, you can use Test::Simple. It's a subset of Test::More functionality, so you can retarget tests written with Test::Simple to Test::More when you need the additional features. Test::Simple has only one method: ok().

Other test modules exist for things like performing web browsing or accessing a database. Most of these test modules combine nicely. Apache::Test specifically is the topic of another talk at YAPC. It appears to provide a kind of "sandbox" for testing. In that vein, it handles issues of hosts and ports, so the test writer doesn't have to worry about it. It uses Test::Legacy syntax, so potentially offers interoperability issues with other testing modules. Test::More support is being added, but should be considered experimental today. Pete showed an example using Apache::Test, which I looked at cursorily, since I plan to attend the Apache::Test talks later today.

Test::WWW::Mechanize can be used to perform traversal of sites. It handles cookies and form values, etc. It can be used with Test::Apache, where Apache::TestRequest::module2url() is used to convert relative URLs to something usable against the "sandbox" Apache instance.

Test::DatabaseRow can be used to perform simple tests against the database. You assign it a database handle to run against, and it can generate some SQL for you.

Test::Expect can be used to test console apps, including tests of remote applications using ssh or telnet. It uses a syntax reminiscent of Expect, as you might expect.

Test::Differences puts test diffs in a table for viewing. This can be useful for determining which parts of a test suite did not behave as expected.

Test::SQL::Translator can be used to verify the correctness of a DB schema.

To determine how much of your code is covered by your tests, you can use Devel::Cover from CPAN. It runs transparently with your tests, and compiles statistics on your code coverage. It can generate HTML output for viewing in a web browser, with color codes.

General tips:

        1. Write a test for each bug you fix.
        2. Automate your automated tests.
        3. Consider test-first development.
        4. Help write tests for others' modules that you use.
        5. Encourage others to test their code.

chromatic & Ian Langworth: Solutions To Common Testing Problems

General Enhancements to Test::More

People usually start with Test::More, but soon end up wanting better diagnostics than it provides. For example, people commonly use is_deeply(). The benefit of using it is that it will highlight, on failure, where in the data structure a disagreement is found. You can use diff to get all differences, but is_deeply() gives only the first point of disagreement. Test::Differences provides a similar functionality but shows all differences. It also shows per-line differences between multiline strings.

When using is() to compare strings, both strings are printed in full. This can be useless for comparison, especially if the strings long. Test::Longstring addresses this problem, via functions is_string(), contains_string(), lacks_string().

Beyond strings, another target of testing is nested data structures. One approach to them is to focus on the composition of the structure, rather than its content. Test::Deep offers cmp_deeply() for this purpose. You can tell is_deeply() what the structure should look like in general terms. One argument to cmp_deeply() is a template for the data structure to be tested. The template can specify an array, a subhash or superhash. Another supported concept is a "bag", which batches bags (i.e., unordered sets possibly containing duplicates).

Testing with Databases

One tricky part of testing is that more than Perl code needs to be tested. One trick you can use is mock objects to mock the DB, but that isn't always the best trick. You can use a different database instead, with test data. Or you can connect to the live system for testing.

To mock the DB connection, you can use the DBD::Mock module. One of the obvious candidates for testing with a mock DB is to test failure modes, such as login failure. In the mock object, you can set flags to simulate login failure, DB connection going away, success, etc.

One candidate for a substitute database is DBI::SQLLite, which accepts SQL commands but has no network connection, multi-user support, etc. This can be used for inserts and selects, without affecting the target DB.

The final approach to DB testing is to use the same DB back-end as the production environment, with a test data set. In the build file, the installer can be prompted for a DB name, user, password, etc., to use in tests. To the end of putting this stuff in your build file, you can use Module::Build. It's much easier than make-maker. Among other things, it provides facilities for prompting users for settings, along with logic to adopt the defaults when performing an automated build.

Testing Web Sites

With Test::WWW::Mechanize you can simulate a web browser to test web sites. It provides methods for submitting forms, clicking links, etc. It also provides test methods for examining titles and other page elements. Another utility, included with Test::WWW::Mechanize is mech-dump, which can be used to examine the structure of a page, for example to learn the name of a form if you don't already know it. Instead of mech-dump, you can use HTTP::Recorder to create a proxy and examine data as it flows back and forth. The proxy can be used to pop up an additional page displaying some information about the exchange. Note that HTTP::Recorder is new and limited: it doesn't handle SSL or Javascript.

The HTML can be validated as a whole using Test::HTML::Tidy. If you only want to check certain things in the HTML you can use Test::HTML::Lint. In response to a question from the crowd: the speakers don't know if there's a handy module for testing XSS vulnerabilities.

Testing with Mock Objects

Mock objects are handy when testing conditions that are difficult to produce for one reason or other: supplying a missing network connection; pretending to reformat the hard drive; simulating obscure failures; etc.

For example, suppose you want to test a bit of code that makes a system call that may or may not succeed on the testing machine (for example, due to lack of speakers at the time of test). This can be done by overriding "system" as follows. Note that "system" must be overrided before the module to be tested is loaded.

        package TestModule;
        use subs 'system';
        *TestModule::system = sub {
        }
        [..]

One word of advice: tests involving mocking like this should probably be run in their own files, so weird things like overridden functions don't have side effects that leak into other tests.

Mock objects to be created for testing with the Test::MockObject. The author has written some articles about Test::MockObject on Perl.com.

Unit Testing with Test::Class

Test scripts discussed so far in this session are procedural. Test::Class treats tests as objects. A new test is created as a subclass of Test::Class. This class implements an analogue of Ruby fixtures, which are services such as the setup and tear-down surrounding execution of test cases. To use a test class based on Test::Class, simply use the module you've created and execute the class method runtests().

There are facilities for skipping tests in units of one class (possibly including all its subclasses).

Another advantage of Test::Class is that you can ship the test classes with your package. Then users that subclass your objects can also subclass your tests and leverage your effort.

Test::Class also facilitates creation of test plans by allowing you to specify test counts piecemeal, and then collecting them into a plan for you.

A Few Cool Things about mod_perl 2.0

The list of mod_perl directives has grown some. The list of classes has grown tremendously.

Writing a PerlTypeHandler didn't work before, because mod_mime has a stranglehold on the request. That has changed. You can now write PerlTypeHandlers easily. You probably won't, because nobody ever needs to, but you can.

What about Apache2::Const::OK? Big changes came right before mod_perl 2.0 because of the "Great Namespace War" of 2004. So now there's something you need to know to migrate mod_perl 2. What you need to know is that all Apache:: modules now live in the Apach2:: namespace. The only exception is Apache::Test. That includes Apache constants, because they are fully qualified by their package:

        - Apache2::Const::OK
        - APR::Const::SUCCESS

But no matter what the docs say, you don't need to use -compile. Just do a:

        use Apache2::Const qw(OK);
        ...

It isn't too hard to migrate to mod_perl 2--you can practically do it with a sed script, as long as you're on mod_perl 1.99. Going from 1 to 2, see last year's talk, "Why mod_perl 2.0 Sucks". But back to what's cool about mod_perl 2.0...

Apache 2.0 has over 340 directives, but only 90 are from "core" Apache. The rest are from extension modules. Those extension directives must be wrapped in IfModule directives in the Apache config. Both versions of mod_perl provide an API for defining new Apache directives, but the API in 1.0 was too intimidating. The 2.0 directive handler is in pure Perl.

Total Access is another cool mod_perl 2.0 feature. Whereas version 1.0 was incomplete, 2.0 offers complete access to everything in the Apache API. There's even a method called assbackwards() (whatever that does).

Output Filters are a new feature in Apache 2.0. Output filters are "things" that allow you to post-process content after the content phase has run. One example of an Apache filter is the one that processes SSI tags: the output of CGI scripts are not run through that mechanism, so CGI scripts can't use SSI tags. Although mod_perl has been able to filter content for years, it was previously only able to process mod_perl output itself. Now it's possible to filter output at a later stage. It's now possible to use mod_perl to filter output of PHP scripts, for example.

Stacked Perl Handlers are an idea borrowed from Apache that mod_perl 1.0 didn't get right. In Apache, how the module list is traversed depends on the phase. In some phases, the handler list is exhausted. In other phases, the list is traversed until the first handler returns OK (authentication is one example of this). The mod_perl 1.0 version didn't allow for early termination on return of OK, but it's now been fixed. One effect of this fix is that PerlAuthenHandler was able to be re-written very nicely, without all the ridiculous workarounds.

To finish with a plug: Apache::Test totally rocks, and you should use it for everything, every time.

Perl Black Magic: Obfuscation and Golfing

José Castro introduced himself by requesting that people stop calling him "Hosé": being Portuguese, the correct pronunciation is Joe-say. From this lighthearted beginning, José proceeded to give a hilarious presentation concerning obfuscated Perl. His pace was much too fast to keep up with, so I won't try to capture his talks in detail. Just remember to check out his slides when they become available at http://www.jose-castro.org/talks/index.html. Here are a couple of teasers:

To impress your friends with obfuscation, you have to give them something that they don't understand right away, but do understand eventually. If, when you explain what a script does, they still don't understand it, they won't be impressed with your cleverness. But if they find out that your incredibly convoluted script prints, "Just another Perl hacker," they'll be impressed.

Some clever ways to make your Perl incomprehensible include:

        1. Gratuitous use of the ternary operator
        2. Adding distractors in the untaken branch of the ternary operator
        3. Using lots of semicolons you don't need
        4. Remove whitespace to enhance unreadability
        5. Never use /// in regexes: "ss from s to s" is much more confusing
        6. Use lots of pound signs, until people can't tell what's a comment and what ain't

Definition: "Golfing" is the art of programming with as few characters as possible. You start, of course, by eliminating all whitespace. And you never use a variable name longer than one letter. Of course you leave off semicolons whenever it's allowed. Above all, you shouldn't forget to exploit the power of Perl's command-line options, of which "-n" is only the tip of the iceberg.

Two clever operators:

        The Eskimo operator: }{

This cute little number looks very confusing, but think what it does at the start of a script invoked with "perl -n"! Check the manpage if you can't figure it out directly.

        The shopping-cart operator: @{{}}

This operator can be used to perform operations within strings, for example, as long as the innermost code block returns a (possible empty) array reference.

Church Politics and Patience

noreply@blogger.com (Len Budney) — Mon, 06 Jun 2005 17:11:00 +0000

It's an enlightening experience, taking part in church committees. I've been on several--though never as a volunteer. There always seem to be a few people engaging in political maneuvers that would seem more at home inside the beltway. You'd think Christians would behave better, but if so you'd be naïve: Christians are people too. On the other hand, Bible-bashers would use those bad apples as proof that Christianity is a farce, but that's intellectual dishonesty on par with arguing that the police force should be disbanded because some cops are crooked.

Seeing these political games first-hand has taught me a lesson or two in patience. It's my nature to be outraged when people spread misinformation, conduct behind-the-scenes campaigns, and try to force issues in their preferred direction. But why? Because it's dishonest? Because it's not Christ-like? I'd like to think that my motives are that pure--that I'm really that driven by principle. Certainly that's part of it. But the main reason I'm so outraged is that I fear these efforts might succeed: the misinformation might be believed; the bad counsel might be followed; wrong-doing may carry the day. In other words, my outrage is partly fear that wrong will triumph, and partly an impatient need to seize control immediately, and to personally make sure that wrong is put in its place.

What I've found, in being forced to handle these things patiently, has been very helpful. For one thing, there are plenty of other men of principle who will do their part, and when I wait I'm often rewarded with such people stepping up to the plate. The world doesn't rest on one person's shoulders. On the other hand, I've also seen that wrong does sometimes win, and there's nothing I can do about it. Sometimes misinformation is believed, slander is repeated, good deeds are punished and bad deeds rewarded. It's rather liberating to wake up to the reality that forcing the right outcome just can't be done by a mere mortal. Scripture says that "evil men and seducers shall wax worse and worse, deceiving, and being deceived" [2 Tim 3:13]. Christ himself said, "when the son of man cometh, shall he find faith on the earth?" [Luke 18:8]. The Bible (not to mention experience) assures us not only that evil exists, but that it often gets the upper hand in this world. It doesn't do any good to go crazy raging against that reality.

Patience becomes possible when we accept that we aren't in control, accept that things will indeed come out wrong, and trust that God is in control and will ultimately put things right. Without trust in God, acceptance of reality makes us cynical and ultimately leads to despair. On the other hand if we don't accept the reality that evil often triumphs in the short term, we will constantly fight battles we can never win. That's a waste of energy at best, and it threatens to weaken our faith in God's ultimate fairness.