The dangers of living in the matrix

Fun story of the week: Hackers broke into the game Shadowbane and changed the game rules:

“At first, players started speculating that there was a really bad bug in the game code,” player Tim Wheating said. “Then we realized that somehow an insane god had taken control of our world and was out to kill us all.”

Of course, if we’re all just living in some big Matrix, maybe this kind of thing happens to us all the time? ;-)

Business world rediscovers good old-fashioned AI

It looks like the world of business programming and web applications has finally gotten with the, uh, 80’s, and discovered rule-based expert systems, according to this Jon Udell column.

Today we program this stuff in procedural languages, and we make a hell of a mess doing so. Wouldn’t it be great if we could declare a bunch of rules and have a rules engine work out the consequences? As Ted points out, this is the moral equivalent of using SQL to say what you want done with data not how.

Although Jess, a Java-based engine developed at Sandia Labs, has roots in both Lisp and Prolog, the emerging business-rules engines work with languages such as Java and C#, read XML-rule declarations, and are packaged for J2EE and/or .Net deployment.

Will rules-based programming just create a different kind of mess? I doubt anyone really knows, but I’m glad we’re gearing up to do the experiment. Sooner or later, something like this has to work.

It’s great to see AI techniques making their way into mainstream programming, but to answer the final question above: Of course, people do know. A whole field of research studies what will and won’t work. And yes, if you get enough rules, it does make a mess, thanks to the lack of a higher-level structured representation for the knowledge.

Luckily, there are tools that provide the necessary higher-level abstractions, like the work of the Rapid Knowledge Formation project here at UT. If you’re bound to doing your stuff in Java (hardly necessary if you’re doing web apps these days), there’s even a Java implementation of Algernon, another UT-grown expert-systems language.

Lakoff: Liberal and conservative moral metaphors

Much has been made in the media and blogs lately of the Democrats’ lack of leadership and a central message to compete with the republicans. In this 1995 essay cognitive scientist George Lakoff analyses the central metaphors that describe and inform the moral systems of American conservatives and liberals. He argues:

While conservatives understand that all of their policies have a single unified origin, liberals understand their own political conceptual universe so badly that they still think of it in terms of coalitions of interest groups. Where conservatives have organized for an overall, unified onslaught on liberal culture, liberals are fragmented into isolated interest groups, based on superficial localized issues: labor, the rights of ethnic groups, feminism, gay rights, environmentalism, abortion rights, homelessness, health care, education, the arts, and so on. This failure to see a unified picture of liberal politics has led to a divided consciousness and has allowed conservatives to employ a divide-and-conquer strategy. None of this need be the case, since there is a worldview that underlies liberal thought that is every bit as unified as the conservative worldview.

Lakoff, himself clearly a liberal, goes on to criticize some of the flaws in the conservative moral metaphor, but is disappointingly short on good constructive advice for Democrats on how to unify their message around their central metaphor, The nurturing parent model. Still, I think that the material is here for good leaders to begin crafting a liberal message that resonates with voters.

M. King Hubbert in his own words

A little digging uncovered Hubbert’s testimony before a House of Representatives subcommittee, in which he discusses his theories on coal and oil depletion, and then goes on to discuss the relationship between interest rates, industrial growth, and inflation. Long, but fascinating.

The Hubbert Curve: passing the peak of world oil production?

A question from the audience at the Howard Dean event in Davenport, Iowa on Sunday mentioned the Hubbert curve for world oil production. The speaker said that this model had predicted that US oil production would peak in the 70’s, and predicted that world oil production would peak in 2005. The implication of the model is that after production peaks, it begins to decline, and it gets progressively more expensive.

I had never heard of the Hubbert curve, but on looking it up, the idea behind it seems straightforward. The total cumulative output of a finite natural resource is modeled as a sigmoid function that begins at zero, ramps up, and then levels off at a constant value when the resource is depleted. The derivative of this curve is the bell-shaped Hubbert curve. On the declining side of the curve, production becomes more expensive, until eventually it’s no longer economically feasible.

This all seems straighforward enough. The trick, of course, is estimating the parameters of the model. Some sites have tried to do this, but I have no idea what their agenda is, and I have no time to do my own analysis. The important thing is that someone does the analysis, and that they do it with a scientific commitment to the truth, since a sound understanding of phenomena like this before they happen is essential to good strategic political decision making now.

Lately I’ve heard the term technocrat used with an insulting connotation to refer to some politicians, like Al Gore. I think the insinuation is that technocrats are cold and somehow heartless, and thus undesirable as leaders. The fact of the matter is that the world is a complex place, and science provides us with tools to understand that complexity, so that we can better make decisions. The Hubbert curve is a perfect example of such a tool. We should embrace leaders who embrace science, who understand that facts and analysis are important, but only useful when the analysis is done in search of the truth, not the political spin du jour.

PowerPoint Thinking

Philip Greenspun points out an essay by Edward Tufte called “The Cognitive Style of PowerPoint” about the particular choices in organization and style of presentation and their detrimental effects on communication. The essay is only available in hardcopy for sale, but on his website he analyses a PowerPoint slide that played a key role in downplaying the risk to the shuttle from the falling foam debris.

As one who admittedly uses PowerPoint and slides in general as a crutch, I think he’s right that it and other slideware programs have changed the way people give presentations, but I’m not sure things are nearly as bad Greenspun makes it out to be…

I’m convinced that PowerPoint has changed the way people prepare and give talks, even people who shun all things MicroSoft. I’ve especially noticed it since I’ve been helping to organize the Forum for AI. Older speakers, who learned to speak before the advent of PowerPoint, seem far more likely to do as Greenspun suggests and use slides only for graphics. In Michael Ryan’s talk for example, his slides were mostly photographs of frogs, and graphical descriptions of the mathematics of his models. He may have had a few slides with bullet points covering important conclusions near the end, but for much of the talk he went for long stretches without changing his slides or refering to them at all. Instead he just talked to us, and he was quite engaging. The venerable Dr. Gerhard Werner, just put a slide with a picture of an ant in the document camera, and then spoke for an hour.

Since starting graduate school, I have not given a talk without using slides of some sort, slides almost always prepared using PowerPoint. I tend to think in outlines. I write all my papers by outlining and filling in, and PowerPoint makes that easy. It especially easy if you use their crappy premade talk templates, which I abhor. But even if you design your slides from scratch, PowerPoint makes it easy to be lazy and just write a bunch of slides that contain what are essentially notes for the speaker, better suited for 3×5 cards. I myself have been guilty of this at times, though I try hard to avoid it.

Still, you can’t lay the blame for speakers’ laziness on entirely PowerPoint. If there was no such thing, speakers would find other ways to be lazy, like writing out their entire talk and reading it to you. I think the thing to remember is that crafting a good talk is something that has to be learned, just like everything else. Except for a few people who are naturals, people who aren’t taught and don’t learn are going to give bad talks, regardless of what tools they use to prepare them.

In many cases, it comes down to each speakers’ personal style. If I’m just standing and speaking, I tend to get nervous and forget what to say. If I have something to interact with (and maybe some notes), the problem goes away. I think I actually do best at a chalkboard, where I can talk with my hands, but that’s not always possible, so I try to make slides with graphics or formulas that I can point to, and that complement and reinforce my spoken words. Sometimes, though, there are long stretches of speaking with no graphics, and I do resort to outlines with bullets, though I try to keep them sparse and avoid more than two levels of hierarchy. Even when in the audience, I find a well-crafted set of bullet-slides helpful, not horrific. They allow me to follow some train of thought started by something the speaker said, possibly missing his next few sentences, and then catch up by reading the slides. It’s also nice to be able to read ahead, get a preview of main ideas, and then have them repeated and elaborated by the speaker.

The key, of course, is that the speaker needs to spend time and effort crafting his talk and slides, and that the slides cannot hope to stand totally alone, without interaction and elaboration from the speaker.

Hackers and Painters

Paul Graham, one of my favorite loquatious Lisp hackers, has written a great essay comparing software design and painting. His thesis is that as an art of making things, software design is really more like painting or architecture than engineering or science. One of the many implications of this view that he explores is choice of programming languages for software design:

A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Lisp, of course, is like this, and so is Python.

The essay touches covers many other facets of software design, and it resonated strongly with me. Check it out.