Summary
...Wherein we look at a discussion on Unix vs. Windows religions and customs, try to make a little sense of it, and talk about designing from the outside in.

---

Advertisement

Okay, it turns out that I may not be the best blogger. I seem not to have a compulsion to write all the time, so it's been far too long since I wrote here. I'll try to do better, but I make no guarantees.

This entry is inspired by an essay by Joel Spolsky, of "Joel on Software" fame. The essay "Biculturalism" is inspired by the book The Art of Unix Programming by Eric S. Raymond. (If you prefer bits to atoms, you can read the whole book online for free, Eric being a famous Open Source advocate.)

[One digression before we get into it: Follow that link to the book above. You will find yourself on a great website for books: Amazon Lite. It's Amazon without all the noisy fluff, and is where I go first now to buy books. Very sweet.]

Joel writes very insightful stuff on software, the process of developing software, and managing software teams. I can disagree strongly with him on things, but he's always thinking hard and well. If nothing else, when I have the chance I'm gonna steal a lot of his ideas about how to design office space for software teams. And I still throw his notes on "Guerrilla Guide to Interviewing" in front of everyone I can.

Joel talks a good deal about the cultural differences between Unix and Windows developers. He sums it up this way: "Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers." All generalizations are false, of course, but this one is less false than most. As a long-time Unix geek, I obviously can argue the advantages of the Unix preference. (For me, it's primarily composability: I can use pipes and the like to put combine useful things to do new useful things, which is really hard with GUI-based programs; see my rant on ant.) And I have a lot of respect for the idea that non-programmers aren't programmers, and need things they can understand. (Composing stuff together is a form of programming, and non-programmers aren't programmers, if you can believe it.)

His primary example is Eric's rule that "Silence is Golden". Basically it says that programs shouldn't be chatty when they're doing what they should do.

If he hadn't cited this particular example you might not be reading this. You see, I suggested this rule to Eric, so I feel particularly responsible. At the time I had been using a program that printed out about 30 lines of verbosity of "Look what I'm up to now!" After the umpteenth time I ran it, I was pretty annoyed at being told stuff that only mattered to someone debugging that program. In other words, it was using up a lot of my limited information bandwidth telling me stuff that mattered to only one person who wasn't me. So I had this on my mind.

The fundamental difference here is that a text-based program has exactly one output channel -- characters on the screen. This makes that space extremely valuable, and therefore not be wasted. A GUI program can spin its state in one text line so it doesn't use up much visual space and is easy to ignore. A screen program has no place to put lower-priority messages.

Joel is right that this is a cultural prejudice, but it's built on unvarnished experience in this ecosystem. Just like the Windows prejudice in favor of "more usability for Mom" is built on a coherent reality that is vital.

Joel himself falls victim to the arrogance of cultural familiarity that he accuses Eric of. Consider this:

When Raymond points out that the CSV format is inferior to the /etc/passwd format, he's trying to score points for Unix against Windows, but, you know what? He's right. /etc/passwd is easier to parse than CSV, and if you read this book, you'll know why, and you'll be a better programmer.

Maybe Eric is pointing this out because it is easier, not to score points against Windows. He also says that self-righteousness is more common in the Unix culture, which shows a certain blindness that comes from being more likely to treat self-righteousness on your own side as just a statement of truth.

Of course, Eric doesn't help himself by having a certain righteous tone himself. You can't read it without feeling that you are thought to be at the feet of a kindly guru, as the picture on the cover makes clear.

Joel almost gets to the meat of things when he talks about Apple and OS X. The years of inability of the Unix market to spread on the desktop have nothing to do, really, with having command line programs and readable text-based configuration files. This are not hindrances, but the cultural prejudice against limiting programmers is. OS X proves that you can put a good GUI on this stuff — Apple's administration GUI is far better than anything Windows can muster. (If you want to prove it to yourself, try setting up wireless cards with encryption on Windows vs. OS X. Oy.) The X11 approach of "Make no choices: enable them" is fundamentally flawed. The world needs a common, clear understanding of how a button works much more than it needs a dozen different buttons, each with comparative virtues. Designing without applying the arrogance of taste is a Really Bad Idea™.

RMI took a better approach. Ann Wollrath first designed what users needed (here "users" means "programmers using RMI"). The mechanisms were internally well designed, but not exposed. Over time more of the internals get opened up to experts who need more than most users. This gives the priority to the 80% most common uses, and when it comes time to expose underpinnings, you know why and for whom. The X11 approach starts building from the bottom up rather than the outside in. You have to guess everything anyone might want to do at every level, making each level a slow and careful slog. After years and years you finally may get to where someone can use what you've done. The RMI approach makes you usable now, and lets you expose what actual experience shows you need to expose, by which time you also know better how people want to use it.

This approach is a much more powerful and productive way to build tools.

Joel says that Eric's book rises above the culturally superior tone, and I agree. Although to be fair, Eric's book is precisely trying to teach the culture, so I think it's fair to believe in it strongly in that context. Still, I might add that Joel's review also rises above its cultural biases. As usual, Joel is worth a good read.

Talk Back!

Have an opinion? Readers have already posted 9 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Ken Arnold adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Ken Arnold is a recognized loose cannon in the software business, whose previous fusilades include being an inventor of Jini, designing JavaSpaces, writing books on Java and distributed systems, helping design CORBA 1.0, and (while at Berkeley on the BSD project) the curses library package, co-authoring rogue, and generally enjoying himself. His interests include designing APIs and programming languages using general principles of human factors design because of his radical hypothesis that programmers are human, and other applications of this same principle to software design, management, and production.