Illustration by Py Staff

A Conscientious Objection to the Holy Wars

Sometimes, instead of asking what a piece of software does, I ask what it means. What mix of social forces and individual desires led to this code being created? What cultural effects are produced by people using it?

One of the best places to see people hack away at these questions, perhaps unwittingly, is by tuning in to computing's holy wars to watch the players debate: vi vs Emacs, Mac vs PC vs Linux, Perl vs Python, Lisp vs the world. At one point, the vi and Emacs folks even had a paintball match (the vi team won).

These fights are always expressed in technological terms. In a newsgroup for C++ programming, someone asks which text editor to use for the most efficient coding, and the fight is on. The arguments take some form like ``my editor is the \textit{best} because it implements technology X. And it (is smaller|has more features).'' It is rare that someone says, ``It's really up to you. Use Emacs for a week, then use vi for a week, then Nedit, and any others that look promising. See which one fits you best, and tell us why you made your choice, so that, in the future, we can understand how to advise people who make this decision.''

This lack of perspective is programmer's patriotism. ``My operating system right or wrong! Linux, love it or leave it!'' When we use a technology or framework for long stretches of time, we invest our time and resources into it. Humans are naturally evangelistic creatures, so it's not surprising that we proselytize for the choices we've made, trying to share them and encouraging others to share our experience. I'm guilty of this as well; right now I'm a staunch supporter of Python, the Semantic Web, and XSLT. I take a lot of heat for liking XSLT. But I enjoy telling people about each of those technologies.

Why would we want to use properties?

Python is a weakly typed language, which as any experienced Python programmer knows has both good and bad points. The main purpose of the properties package is to help address cases where weak typing leads to problems. In particular, the motivation for properties came as a direct result of work done on Chaco, an Open Source scientific plotting package.

Chaco provides a set of high-level plotting objects, each of which has a number of user settable attributes, such as line color, text font, relative location, and so on. To make the objects easy to use by scientists and engineers, the attributes attempt to accept a wide variety and style of values. For example, a color-related attribute of a Chaco object might accept any of the following as legal values for the color red:

An analogy: some people, given a new house, like to furnish it sparsely; others want a riot of bookcases. It's rare for anyone, except a parent, to tell you how to furnish your home, to insist that it be done in teak or that your table must be aluminum. Domestic environments are seen as deeply personal. But every serious computer user has a list of must have tools, many of which have equally well-functioning alternatives. You need vi, the functional living room with a chair, a couch, an aluminum coffee table, and a Bose stereo in the corner. Or you must use Emacs, which is the family room with mail piling up, the TV on, the walls painted different colors, and a kid in a playpen screaming the GNU license over and over. If you're only editing text, some might advocate using something like Microsoft Word, which is an entire Ikea, on fire. Full disclosure: {GNU Emacs 21.2.1 (i386-msvc-nt5.1.2600)}.)

Behind all that advocacy, there is a great deal of passion. But there is also a great deal of fear, a sense of threat. Ellen Ullman, in her autobiographical book about programming, \textit{Close to the Machine}, writes:

"The corollary of constant change is ignorance. This is not often talked about: we computer experts barely know what we're doing. We're good at fussing and figuring out. We function well in a sea of unknowns. Our experience has only prepared us to deal with confusion. A programmer who denies this is probably lying, or else densely unaware of himself. "

When I read the threads of the holy wars, archived forever via Usenet and mailing lists, I see people fighting back against their fear of the ignorance Ullman describes. Some Emacs users see vi as a threat, rather than as a fellow traveler, and vice versa. Linux people and Perl people and Applephiles all go at it, lashing out at each other. My all-time favorite platform, the Amiga, still has people insisting it's better than anything on the desktop today. Which, considering you can emulate an Amiga exactly on most OSes, and still have the parent OS around it, simply cannot be true.

What advocates rarely do is discuss the question of audience, and rarely do they consider the user's daily needs. One way to start talking about software is to look at who developed it and why. Emacs was designed by Richard Stallman, an all-purpose hacker and LISP-lover working at the MIT AI lab. vi was developed at Berkeley by Bill Joy, based on the line editor ex, based in turn on the line editor ed. When we look at the origins of each tool, we see very different urges: Emacs, which is nominally based on the ideas in the TECO editor, was always intended as its own thing, an environment where serious work could be done and text could be atomized and manipulated by LISP functions, allowing them to metaprogram their programming environment.

vi, on the other hand, was built on top of the tools that made up the Unix ecosystem, where the focus has always been on fast, small, and quick ---at the expense of cryptic. Yes, vi has been extended, especially through Vim; and yes, given processor speeds, Emacs now runs almost as quickly as Vim. But perhaps the origins of each gives us clues as to how they could be used. Maybe Emacs is the better tool for the person who's going to be writing a compiler from scratch, where the ability to metaprogram could be very useful. But the person hacking together shell scripts every day on a variety of remote terminals might find vi far more useful. The real question is never, "what is the best text editor"; that's like asking `what is the best novel' ---an academic exercise at best. The question is "what is the best editor for me.'"

The same issue holds true for languages. Often, when a new language is introduced on Slashdot or in other discussion groups, or an old language which still has users is described, a "community" comes out to disparage it. "We already have enough languages!" they say to people who like Rebol, or Lua. "C++ won, get over it!" they say to fans of Scheme or Ada or COBOL.

These responses are useless. Of course, the standard computer-journalist thing to write would be "...Scheme or Ada or, GOD FORBID, COBOL," to wink and nod that, yes, I think COBOL is a syntactic horror deserving of mockery. But, truthfully, I don't. It fit into its time, a great number of people learned it, some liked using it, and millions of lines of code were written in it. Its time is probably over, but to someone still using it, more power to them. It's not a real language? So?

It would be far better to give people the ability to self-identify. ``I am new to programming and I want to learn how to program dynamic, database-backed web pages,'' they might say. And we could counter with Python, Perl, or PHP, arguably the three best CGI languages with moderate learning curves. Then we could identify their tasks within this subdomain of languages. Are they munging a lot of text? Perl might be the best-documented solution for these problems. Building complicated frameworks? Python. Need quick and dirty development and fast execution? PHP.

This is familiar advice, but it's hard to do in practice. When someone asks "what language should I learn," the answer should never be, "Python!" or "PHP!" Rather, it should be, "Who are you, and what do you want to become?"; and, then, lastly: "What do you want to do?" A pure hobbyist programmer interested in computer science may get more from Scheme than she might from learning any of the dominant scripting languages.

Why does this matter? Because more and more, programmers will be asked to give advice. As more and more people come online and start wondering how to do more with their machines, and as more kids grow up without a fear of digging deep inside the computer, programming will almost certainly become something more personal and less unusual. Just think of camcorders, which people use to take control of their TVs. The great thing about camcorders is that they have a very easy entry point ---just hit record --- and then the work you can do in editing, overdubbing, scripting, and so forth is limitless.

On the PC, Python's tutorials and public documentation are one such entry point; Java's BeanShell is another; tools like "batch filter" in Photoshop or "Schedule Tasks" on Windows are yet others. Given all these different approaches to algorithmic thinking, it will increasingly be our responsibility to help the people around us find ways to enter into programming --- even though it may not be known as programming per se --- as part of daily work. The main entry point right now seems to be the Web. HTML provides an easy way in, but then, working out from the idea of the page of text and images, people want to know more. As a result, a huge number of people are walking around today with a fluent understanding of interface design, database development, and basic programming --- far more people than anyone 15 years ago might have expected.

Given the amount of wasted time spent in holy wars, I think our way of talking about our favorite tools should be modified. We should talk about them as we might talk about our favorite novelists or films we love. We can accept that someone may not care for Richard Russo, or Octavia Butler, or Stanley Kubrick, but for some reason it's extremely hard for some programmers to understand why everyone doesn't quit their jobs, reinforce their parentheses key, and program only in Scheme.

I've seen Perl hackers lament the loss of freedom Python's indented style presents, as if something great was being taken away from them; the mere presence of Python, the nefarious upstart, threatens them. They respond to praise of Python like a fan of James Thurber might respond to someone saying "James Thurber is never to be read again, now that we have Dave Barry. For all humorous reading, refer to Dave Barry!" As a class, programmers are supposed to be the most avid futurists. But in truth, we're often amazingly conservative. I think if we were a little less focused on what made a solution technologically superior, and a little more on what makes it personally relevant, we'd be able to serve each other more fully. And by doing that, we'll serve the interests of strangers, friends, and our users, and make them more like us, people who are engaged and excited by the opportunities presented by programming.

 Py is committed to bringing you great Python Articles.