So, if you'll forgive me, I'll talk about Basic yet again this month. But not just Basic. With all the noise about Microsoft's XP, it seems timely to remind ourselves of another XP, the programming discipline called "Extreme Programming," recalling what it's about and asking what its role is in software development circa 2001. So I'll touch on that here, too.

Despite the recent indications that I have some sort of obsession with Basic, the truth is that if I had the courage of my convictions, I would do all my programming in Lisp or Prolog, languages for which I have an incurable academic fondness and nostalgic attachment. So I want to show you a neat little parallel between Prolog programs and some of the structures needed for this Semantic Web thing that Tim Berners-Lee has been promoting. (Double congrats to TBL, BTW, who became an FRS this year while his WWW celebrated its 10th birthday.)

I also use the Rebol language for some tasks, and the Rebol crew is currently promoting something called the "X Internet." This is not XP (Microsoft's or the other one) and not the Semantic Web, but what is it, exactly? I'll try to nail that down by the end of the column. In a way, this is a backward- and forward-looking nostalgia-for-the-future kind of column this month, and where better to start the nostalgification than with the lost innocence of Bill Gates.

Bill's Lost Code

Finally, after 25 years, the source code for the original Altair Basic has surfaced. I can't show it to you here, but you can see it for yourself, or at least a very good copy of it, at Bill's alma mater. The code was long sought by journalists and historians. Back in 1987, a French journalist, André Warusfel, asked Bill Gates if Bill still had the code, and if so, would he make it available. Bill said that he did and that he would, but he didn't. Apparently Bill never found the code, if he ever looked for it, and over the years others, especially David Mery, repeatedly bugged him about this missing 8080 assembly code, but to no avail.

Then, in 1999, the code suddenly came to light. So back-burnered had my own desultory search for the lost code become that I didn't even notice that it was over until this spring. The listing in question had gotten shoved down behind some piece of furniture in an office in Harvard's Aiden Computer Laboratory back in 1975. This piece of furniture may have been a filing cabinet, or then again it may have been something else. The sources are inconsistent on exactly what kind of piece of furniture it was. In any case, rescued from this hidey-hole in 1980, it lived forgotten in a filing cabinet (definitely a filing cabinet) for 19 years, until 1999. With Bill's permission, it now resides in the Pusey Library at Harvard.

Actually, it's not quite the original, if you go by the version number. What Harry R. Lewis, the Gordon McKay Professor of Computer Science and Dean of Harvard College, found in that filing cabinet is marked with a version number 1.1. And what's on display in the library is really a recent copy. Gates and Allen also now have copies, and the original is locked up somewhere.

What's there is 114 pages of code, constituting the 4K and 8K Basic source. Gates is credited with writing the run-time stuff, Paul Allen the nonrun-time stuff, and Monte Davidoff the math package. The copyright, though, is in the names of Gates and Allen.

Yeah, yeah, but was Gates any good?

So now that we can examine the evidence, what's the verdict? Was Bill Gates a good programmer, or just the luckiest person in the world? Actually, we didn't have to wait for the printout to answer that. Reuben Harris has disassembled an early Altair Basic binary, and his conclusion is that the 1975 Bill Gates was a true hacker in the finest sense of the word.

In more than one instance, for example, Gates's code jumps to the second or third byte of a 2- or 3-byte 8080 instruction. What looks like an error is just a way to save a byte here and there.

This is what some might call "running light without overbyte." And that was what mattered in 1975. Dennis Allison, this magazine's cofounder, once told me that there is only space and time, and you have to decide which to conserve. (Those are not even remotely his words, but I'm pulling this one out from behind my own mental furniture after more than a decade. He did say something to that effect.) In 1975, when speed was a luxury and saving 3 bytes might mean the difference between being able to implement a feature and not being able to implement it, what you conserved was space. Bill was very good at this.

As were Allen and Davidoff, I suspect.

And what about Davidoff? He's got his own business these days, Alluvial Software, where he programs mostly UNIX systems and sings the praises of Richard Stallman and the other Free Software and Open Source Movement heroes who are making his old friend Bill so nervous these days. His favorite language is Python.

Extreme Programming: An Anti-Executive Summary

I met with Kent Beck over lunch recently, and we did that author thing of exchanging copies of our books. For whatever reason, I hadn't gotten around to reading Kent's book Extreme Programming Explained, (Addison-Wesley, 2000, ISBN 201-61641-6), so I was grateful for the autographed copy and dug into it immediately.

My previous exposure to the discipline of Extreme Programming had been through the writing of Ron Jeffries, but Kent is the guy who more or less invented Extreme Programming (XP).

He's also a thoughtful and entertaining writer. Before I knew it, I had zipped through two books in the Addison-Wesley XP series, the other being Planning Extreme Programming by Kent Beck and Martin Fowler (Addison-Wesley, 2001, ISBN 0-201-71091-9), and had refreshed my memory on XP. Perhaps I can do the same for some of you, or point others to Beck's books. Kent is quick to point out that the ideas in XP are not his invention. They are good programming practices and principles, many of them probably as old as coding. Some are just good ideas in managing any complex task. But XP represents a cogent rethinking of the interaction of these practices and principles, and results in reduced project risk, better responsiveness to business changes, and greater productivity throughout the life of the system.

That, anyway, is the claim. XP has its supporters and detractors, but it also evokes in people a characteristic mixed reaction. I saw that reaction when I participated in a panel discussion recently. One of the other panelists delivered a stirring extemporaneous pitch for XP, but when I asked her later if she were an XP devotee, she denied it. She was very curious about XP, she said, but not a devotee. I gathered that she couldn't see how it fit into her work. That reaction seems to be common. Part of the appeal of XP is its programmer-centric worldview. Among programming methodologies, XP must be, at least at first look, the least appealing to corporate bosses (unless they happen also to be programmers), because it puts the business people and the business interests firmly in their place, and elevates, or rather highlights, programmers and their issues. It works, though, at least for some people and some projects.

But if Extreme Programming is just a new selection of old practices, what's so extreme about it? Kent's answer is that it takes obvious, common sense principles and practices to extreme levels. For example:

• If short iterations are good, make them as short as possible — hours or minutes or seconds rather than days or weeks or years.

• If simplicity is good, always do the simplest thing that could possibly work.

• If testing is good, test all the time. Write the test code before you write the code to test.

• If code reviews are good, review code continuously, by programming in pairs, two programmers to a computer, taking turns looking over each other's shoulders.

There are other principles and values that define XP; Kent's book is a good place to learn about them.

XP differs from most programming methodologies in that it doesn't encourage a lot of up-front planning. XP assumes that the goals will change repeatedly in the course of the project and emphasizes flexibility. In this, it seems much more in tune with the realities of software development in the real world — anywhere outside NASA anyway — than other methodologies. That may be another thing that attracts people like my friend on that panel to XP.

What gives them pause, I suspect, is the team programming. It's certainly what keeps me from implementing XP in my programming. Ain't got no team, can't do no team programming.

Extreme Programming And Open-Source Projects

The requirement — and Kent insists that it is a requirement — of programming in pairs is particularly difficult for open-source projects, in which programmers collaborating on code may not even be on the same continent. But many XP principles and goals are shared by open-source development.

Open-source projects are typified by short release cycles, by programmers reviewing one another's code, by an openness to patches, by programmers working on the parts of a project that most appeal to them or for which they just got an idea — all of which typify XP development.

Can XP be applied to open source? Since open-source projects are characterized by voluntary participation, I don't see how any programming methodology can be imposed on them. But XP principles can be promoted and encouraged in open-source projects, as they seem to fit, and there is nothing to prevent programmers working on an open-source project from working in pairs.

As one developer who goes by the handle chromatic has pointed out (http://linux.oreillynet.com/pub/a/linux/ 2001/05/04/xp_intro.html), to the outside observer both XP and open-source development look like pure chaos. "Somehow, though," chromatic says, "order emerges, and programmers produce good code that meets requirements and meets or beats the schedule and the budget. At least, when [the methodology is] applied properly. The secret is knowing when, where, and how much." Kent Beck agrees that XP isn't for everyone, everywhere. "There are times and places and people and customers that would explode an XP project like a cheap balloon," he says. "It is important not to use XP for those projects."

And he understands that some people will pick those aspects of XP that they like and skip the others, which may happen — may be happening — with open-source projects. "There are practices in XP that are a good idea regardless of what you think about the whole picture. You should do them."

Prolog, RDL, and the Semantic Web

I talked about the Semantic Web last month. Its goal is to empower programs and machines to reason about information by virtue of having some understanding of what that information actually means. One of the core technologies necessary for the realization of the Semantic Web is RDF/RDF Schema, which can be thought of as a language for the description of things and their associated types.

As Bijan Parsia wrote on April 25 over at xml.com, the Semantic Web is really an artificial intelligence project, if only the words "artificial intelligence" weren't poison in the public perception. And RDF has a strong affinity for one of the primary languages used in artificial intelligence work, Prolog.

Prolog programming consists of building a knowledge base of assertions and querying it. An assertion, which looks a lot like a function, asserts some fact. (It's a fact as far as the knowledge base is concerned, anyway.)

owns(mike_swaine,moby_dick).

is a Prolog assertion. There's a subject-verb-object structure to these assertions, usually. In this case, mike_swaine is the subject and moby_dick the object of the verb (technically, the functor) owns. We might want to be clearer about whether it's a whale or a book that I own:

owns(mike_swaine, book(moby_dick, herman_melville)).

We use the following syntax to query the knowledge base:

?- owns(mike_swaine, book(moby_dick, herman_melville)).

This Boolean query will return True or False when run against the knowledge base consisting of our one assertion.

?- owns(mike_swaine, Book)

is a more interesting query because it contains a variable. (The syntax convention is that terms starting with a capital letter or underscore are variables.) Run this query against our knowledge base and you get the response

Book = book(moby_dick,herman_melville)

Using RDF/RDF Schema, you also find yourself producing three-term structures consisting of

• a predicate (a URI),
• a subject (a URI), and

• an object (a URI).

It's ridiculously easy, if somewhat cumbersome, to map these RDF triples to Prolog assertions:

"http://www.bookstore_database/functors/ owns.html" ("mail:[email protected]",

"http://www.bookstore_database/books/ moby_dick.html").

Judicious use of namespaces can declutter such an expression.

So far this is just representation, but Prolog's power is in what it lets you do with these knowledge bases once you've built them. Prolog is the closest thing there is to logic implemented as a programming language, and it is ideally suited for deductive reasoning and proof construction, which are items on the To Do list for the Semantic Web. Prolog provides a wonderfully natural way of expressing facts, and a naturally wonderful way to implement a logic layer on those facts, putting the AI in the SW.

What's This X Internet?

George Colony, the CEO of Forrester Research, not the doomed fisherman in The Perfect Storm, coined the term "X Internet." It's his buzzword for encapsulating his contentious contention that the Web will be replaced in a couple of years, just as the Web itself replaced WAIS and Gopher, and that it will be replaced by a new paradigm of distributed executables.

Distributed, peer-to-peer Internetworking is clearly on the rise, and you'd have to be blind not to be aware that executable, live content is more and more with us. Nothing profound in noting these trends. Colony's boldness lies in claiming that this executable Internet paradigm will replace the sharing of ordinary content. That's bold and, it seems to me, about on a par with predictions of the paperless office.

Words and pictures aren't going to go away just because we've figured out how to make refrigerators talk to DVD players. Even if new protocols replace HTTP and HTML, I don't see the investment in good web sites with useful content turning to dust under the wheels of the X Internet. That said, the Executable Internet is a powerful idea, if not a particularly original one. It has a large overlap with the Semantic Web, but a more marketable name.

Mac developers: Next month I'll report on some feedback from attendees at Apple's Worldwide Developer Conference, which took place in May. Meanwhile, have you discovered http://www.macintoshdeveloper.com/ yet? It's DDJ's site for Mac programmers, and features daily news briefs, columns, and other goodies — including a column by yours truly.

DDJ