Channels ▼



Source Code Accompanies This Article. Download It Now.

Nov02: Programming Paradigms

Michael is editor-at-large for DDJ. He can be contacted at [email protected]

Most newspapers and magazines don't publish their errata on the front page for the same reason that most people don't wear their underwear on the outside. Of course, some people do wear their underwear on the outside. Some Dr. Dobb's readers may wear their underwear on the outside, and to these readers I want to say that I mean no disrespect. Now that I think about it, it seems to me that programmers who wear their underwear on the outside ought to be strong proponents of Open Source software, which I respect highly—but I could be wrong. Easily. I know very little about style, slightly more about Open Source software, but a lot about being wrong.

Being wrong, or more specifically, the fear of being wrong in public, may be one of the unmentioned reasons for opposition to Open Source software. Embarrassment over the quality of one's code, or over what one's code might reveal about one's skill level, background, character, or personal habits, can make one reluctant to let one's peers peer at it. Does the possibility of embarrassment, or just a sense of modesty or privacy regarding the product of one's efforts, put some constraints on what kind of community the community of software developers might be? Or is there such a thing as a community of software developers?

This month's column touches on some issues regarding community in software development, drawing so loosely from books and articles and news stories that their authors should be held blameless for the liberties I take with their ideas. I'll state right up front that this column does not address the sociology of distributed computing, the effect of social network topology on project effectiveness, Open Source culture or blog culture or mailing list culture or culture jamming or cyberculture or dot-com victim culture, net mass psychology, or the politics or economics of Free Software. But before you breathe that sigh of relief, I must caution you that I might write about any or all of those topics in a future column. To a hermit like me, the idea of people talking with one another about their work probably seems more novel and innovative than it does to a normal person, so if there are any normal people in the Dr. Dobb's readership, they should take this as a warning.

The Community of Writers

There is an ancient, tiresome, and unresolved debate over whether programming is more a science or more an art. The question gets measurably more interesting if you make it personal and ask yourself, "When I am writing code, do I feel more like a scientist or more like an artist?" Well, how does a scientist feel? How does an artist feel? It turns out that the difference may have a lot to do with one's sense of community. At least that's how I interpret Alan Lightman's analysis of the question. In "The Physicist as Novelist," an essay by physicist/novelist Lightman in The Future of Spacetime (Stephen Hawking et al., W.W. Norton & Company, 2002; ISBN 0-393-02022-3), the author examines the similarities and differences in how it feels to be a scientist (specifically, a physicist) and an artist (specifically, a novelist). One big difference that he finds is in the sense of community.

Although he's clearly not talking about hermit scientists like Dean Kamen and Stephen Wolfram, nor about the growing number of so-called scientists working on the corporate dole and nailing down their "intellectual property" rights before sharing anything, Lightman accurately characterizes a typical working scientist as a person who works closely with dozens of colleagues, usually in a university or laboratory where he or she is surrounded every day by colleagues, exchanges daily e-mails and telephone calls with remote colleagues, gives seminars on new research, submits new papers for peer review, and attends several conferences a year. That's the community of a scientist.

A novelist, on the other hand, works at home and alone. Novelists rarely attend meetings of any kind, they talk with other novelists rarely and then guardedly, and they prefer to deliver a finished work without input from anyone else. "A novelist lives in the desert," Lightman says, "he has evidence of the existence of other novelists mainly through the occasional footprints he stumbles upon, in the form of books and reviews. He reads other writers' books with admiration and jealousy, then goes back to his one-man tent. That's the community of writers."

I agree with Lightman's characterization—or caricature—of writers as loners. Heck, I exemplify it. (I resemble that remark.) But writers do get together occasionally, especially when they are learning their craft. I think that the most effective way in which writers can get together as writers, aside from the rare successful collaboration, is in writers' workshops.

In a writers' workshop, a group of 10 or so writers, aided by a group leader or facilitator, critique one another's writing. There are some firm rules. The writer whose work is being critiqued just listens; no defending the work. The critics must sincerely try to be helpful and be considerate of the writer's feelings. Often, their criticism follows a strict pattern: First everyone summarizes in neutral terms what they think the work says, then each gives positive feedback, then each offers advice on improving the piece. There are time limits. Despite the rules and best intentions of all involved, hurtful and maddeningly misguided comments do get made, and it can be really hard for the victim to adhere to the no-defending rule. But the overall effect can be as affecting as a group therapy session. (And maybe more useful.)

I've done a few (writers' workshops, not group therapy sessions), and they changed my writerly life. The experience is scary, because you're asking strangers to kick all the props out from under your self-esteem. But the payoff is often commensurate with the risks. What I find surprising is that writers' workshops can be useful for software developers, too.

Getting Programmers Together

Like Alan Lightman, Richard Gabriel has a foot in two worlds—programming and poetry. Gabriel is one of the original SAIL Lisp hackers, author of books on Lisp and patterns, coauthor of Sun's Community Source license, ACM Fellow, founder of Lucid Technology, and originator of the "worse is better" software development philosophy. He's also a published poet. These days he writes both poetry and code, and in the past few years, he's been blurring the line by putting on writers' workshops for programmers. In fact, he's written a book about the process: Writers' Workshops & the Work of Making Things (Addison-Wesley 2002; ISBN 0-201-72183-X).

The workshops that Gabriel describes and that he and others have been running since 1994 are not coding workshops, though. They are aimed at the software patterns community as a way to improve patterns and pattern languages and to share knowledge about patterns and pattern languages. The genesis of these workshops was a meeting of the Hillside Group in California's Santa Cruz mountains just down the hill from my house (at that time). I could have biked down if I had been made aware of the conference, but nooooo.

Ah, well. That conference was officially intended to promote the ideas of architect Christopher Alexander that launched the software patterns movement. Unofficially, it was a gathering of "friends of Kent Beck." Curiously, Beck is now a neighbor of mine here in Oregon's Rogue Valley and comes into the restaurant now and then. (I'm sure there's an insight about community in that fact, and when I figure it out, I'll get back to you.) Gabriel had participated in some writers' workshops in his other life as a poet and proposed that the Hillside Group adopt the writers' workshop format for its discussions. The suggestion was roundly ridiculed. But then they tried it anyway.

And it worked.

It may be that it worked only because software patterns are a kind of literature, much more than programs are. In any case, it worked, and has continued to work for toilers in the field of software patterns (not to mention novelists and poets). And it has everything to do with community, because writers' workshops both presuppose and engender a kind of community. I'm not sure how to describe it, but Gabriel thinks it has to do with the gift economy. In a gift economy, gifts given form a bond of mutual obligation. In Open Source software development, the gift is source code, reciprocated by suggestions, bug reports, debugging, praise, and more source code. In a writers' workshop, the gift of sharing a work in progress is reciprocated by suggestions, comments, and praise. Rather than the precise tit-for-tat of money economy, the gift economy creates a climate of mutual obligation. However it works, I know that successful writers' workshops build a sense of community.

Community of Two

Kent Beck himself promotes a special kind of community of programmers—the community of two. Extreme Programming (XP), of which Beck is at least one of the creators, requires that developers collaborate in pairs to write all production code. That's not the only defining feature of the methodology, but reports from those who've worked on an XP project indicate that this requirement alone changes the social dynamic of programming more than just about any other change you could make. Some think that this is a good thing, and others—don't. XP has its supporters and detractors, and has attracted some misconceptions and questions about what really is essential to XP. Responding to this, Pete McBreen has written Questioning Extreme Programming, (Pearson Education 2003; ISBN 0-201-84457-5). It's interesting that McBreen's book is in the Addison-Wesley XP series edited by Kent Beck, because it's a pretty anti XP book. McBreen says he came to praise XP and ends up burying it. Or at least arguing that XP is only appropriate for a very small set of projects and that it generally is not worth the cost to change to XP unless your current methodology is clearly broken and everybody involved wants to use XP.

McBreen clearly understands XP, explains it clearly, and examines its claims and the consequences of applying its techniques, although Beck doesn't think that McBreen understands its scope. He does understand that it presupposes a different kind of interaction, a different kind of community.

McBreen thinks that the rhetoric of the XP champions may have confused outsiders about just what kind of community XP presupposes or engenders. Is XP a cult? Are XP programmers just a bunch of undisciplined cowboys? Hostile? Joyful? Extremists? Hostile joyful extremists? None of the above, McBreen says. They're just programmers who like to program and want to be appreciated. Which leaves me still wondering what kind of community the XP community is.

(Quibbles: If we readers of McBreen's book can understand "requirements creep" without explanation, we probably didn't need his lengthy explanation of the phrase "paint oneself into a corner." And he either badly misunderstands Marc Antony's funeral oration in Julius Caesar or he has a secret agenda to discredit XP. I assume the former.)

The DDJ Community

Whether writers or programmers have a community or not, some writers who write about programming do. I refer to the DDJ community, a community that has been around long enough to have traditions and history (the magazine was founded in 1976). Just last week, I got e-mail from a DDJ writer I first met in 1984 when I bought an article from him. DDJ editor-in-chief Jon Erickson is about to celebrate his 15th anniversary with the magazine. But Jon and I are the younger generation: People's Computer Company, the entity from which DDJ sprang, is 30 years old. At the People's Computer Company site (, you can connect with the real old-timers, like Dennis Allison and Bob Albrecht, who founded DDJ.

The PCC site also has an interesting collection of links and references to such disparate topics as gift economies and the Internet, mathematics, and programming languages. One item described on the list but not linked to (because it can't be found on the Internet) is a nifty collection of machine-language-level programming tricks. That list was recently turned into a book by its compiler, Henry S. Warren, Jr.

The tricks in Hacker's Delight (Pearson Education 2003; ISBN 0-201-91465-4) are very small tricks. They mostly involve clever things to do with bits. They assume that you're working on a machine that represents integers in twos-complement form and that you are running with integer overflow interrupts turned off; and they freely mix arithmetic and logical operations.

The book is not just a random collection of tricks, though. It is well organized, and Warren tends to explore a topic—say, counting 1 bit in a number—rather exhaustively. He helpfully includes a large table of identities that involve both arithmetic and logical operations, like:

- not X = X + 1

not - X = X - 1

The book covers counting bits, rearranging bits and bytes, multiplication and division, Gray code, and formulas for finding the nth prime, among other topics. This is the kind of book that would have been devoured by DDJ readers back in 1976, and is still pretty tasty today.

Algorithm Breakthrough

Not in the book, but much in the news, is Manindra Agrawal, Neeraj Kayal, and Nitin Saxtena's breakthrough 13-line deterministic polynomial-time algorithm for deciding whether a number is prime. As you can see in Example 1, I've modified the notation a little to appease my word processor (and broken it into a few more than 13 lines). You can find an unmodified version of the algorithm with discussion at The existence of a polynomial-time algorithm for primality is no threat to encryption security, but the fact that undergraduates could crack such a long-standing problem makes it more plausible that someone could still come up with a fast algorithm for finding prime factors, and that would be pretty catastrophic.

But what do any of these coding tricks and algorithms have to do with community? Only that they are freely shared. Community is mostly about sharing, it seems to me. I guess it's that gift economy thing.

On Being Wrong

I must say it warms my heart how freely the current DDJ community, also known as you, share with me whenever I make a mistake in this column. I'd like to create a space on the DDJ site for feedback and errata. Until I do, I'll thank here all those who reminded me that TSR stands for Terminate-and-Stay-Resident, not, as I erroneously wrote, Terminate-and-Stay-Ready. Hmm. If I make a bonehead mistake like that when writing about a topic I know something about, just imagine how many mistakes I may be making in writing about this next topic...

The Quantum Thread

I've been spinning a thread about quantum computing in this column most of the past year, and maybe it's time to answer an extremely practical question about this presently largely impractical subject. I do know one programmer who truly lives in the gift economy, but most of us have to go the paycheck route. Are there any paying jobs in quantum computing? Academic programs that lead to paying jobs? Any fellowships? Teaching assistantships?

Sure there are, and the phrase you need to commit to memory in searching for them is Quantum Information Science. QIS is the new discipline that includes quantum cryptography and quantum computing, and it is getting NSF funding. A good place to see what the U.S. government thinks of this emerging science is this URL for a conference held a few years ago: nsf00101.htm. I hope the URL sticks around; if it doesn't, drop by the Institute for Quantum Information at Caltech ( It's a hub of the QIS community.


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.