2007-05-24 09:21:19
看过很多关于Unix/Linux和Window之争的文章。即使是我这么偏爱Unix/Linux的人，都会觉得那些文章中的绝大多数太过偏激，要么把Windows贬得一无是处，要么把Windows美化得白璧无瑕。
我的工作不是windows编程，我也很不喜欢Windows编程，可我的日常工作生活仍然离不开Windows。即使像我这样的程序员，让我在Linux/Unix下配置一台打印机，或者安装一个声卡，也是让我头疼的事情。Windows之所以如此流行，决不是偶然，有它内在的深刻原因。Unix/Linux的设计很优美，实现也很优秀，但是为什么在某些领域（尤其是桌面系统）干不过Windows？Unix/Linux社区的人对自己的技术水平一向非常自负，为什么十多年过去了还没能取Windows而代之？这些问题我回答不了，但我的直觉和唯物辩证法都告诉我，任何一个事物都有对立统一的两个方面，Windows也有它的优点，Unix/Linux也有它不尽人意的地方。
最近看《Joel on Software》专栏，发现这个专栏作者发布在2003年年底的一篇文，把这个问题讲得一清二楚，态度公允，分析深入，值得一读，对系统设计来说也很有指导意义。为了给自己加深印象，节选其中一部分翻译，做笔记。
------------------开始啦-----------------
Unix和Windows从功能上看越来越相似，剩下的不同仅仅是文化差异。举个例子：我们都要吃东西。大洋彼岸的人们用筷子，吃生鱼片就米饭；但我们用手拿着面包，就着牛肉吃。文化差异并不意味着美国人消化不了生鱼片，或者日本人消化不了麦当劳的汉堡；实际上美国很多人吃生鱼片，日本也有很多人吃汉堡包。但文化差异确实意味着，一个美国人第一次踏上东京的土地时，总会觉得这地方怪里怪气。尽管哲学上讲，所有的人本质相同，都会恋爱工作唱歌死亡，美国人和日本人仍然很难适应对方国家的厕所布局。
Unix和Windows程序员的文化差异是什么呢？我们暂且不细说这里面的细枝末节，最重要的一点差异是：Unix文化重视那些对程序员有用的代码，Windows文化重视那些对非程序员有用的代码。这么说有点简化，但最大的区别的确就是这一点：我们是为其他程序员设计程序，还是为最终用户设计程序？此外的任何问题都是对这个问题的注脚。
20世纪60年代末，Unix刚刚诞生，Unix社区的核心文化正在形成，当时的计算机没有“最终用户”。那时的计算机，以及计算机的CPU时间，都很昂贵，都仅仅用在很专业的学术领域。“学习计算机”就意味着“学习编程”，而不是像现在这样，“学习使用应用软件”也是“学习计算机”的一种方式。作为现代的最终用户，你可能根本不会编程，而仍然能用计算机做许多事情。但上世纪60年代末，尤其对Unix社区来说，“用计算机”就是“编程”。Windows被制作出来的时候，唯一的目标是出售尽可能多的拷贝，以赢得更多利润。“每家的每张桌子上都有一台安装了Windows的计算机”是Windows开发小组的理想，这一理想为windows设定了核心价值观：对最终用户来说更容易使用，但显然，绝大多数最终用户不是程序员。Windows开发过程并没有把“方便其他程序员”作为目标。
例如，Unix的一个重要原则就是“清晰区分策略和机制”。该原则源于X系统的设计。（虎注：X为Unix系统上的图形用户界面的基础设施，其设计者明确提出，X实现的“是机制，不是策略”——X是一个通用图形引擎，用户界面风格的选择，应该是toolkit以及系统中另外一些级别上的决策。策略和机制都会有演进，但是他们变化的速度不同：策略的变化一般比较快，基本机制的变化则比较慢。图形用户界面的风格经常变动，但是用于显示用户界面的基本光栅操作——比如在屏幕上画点/画线——则没有太多变动余地。）“清晰区分策略和机制”这一Unix文化中的基本原则导致了Unix上图形用户界面风格的多样性。Unix世界里从未就用户界面工作方式的全部细节达成一致，并且他们认为这没什么不对的，Unix文化并且还尊重这种多样性。但是对一般的最终用户来说，在两个应用程序中，应该能用相同的操作（点击相同的按钮或者菜单/快捷键）达到相同的目的，这样的系统上的应用程序才是易学易用的。也正是由于上述区别，虽然Unix开发者为给Unix做一个漂亮的用户界面已经努力了二十年，我们还是看到最大的Linux厂商的CEO告诉大家：“家庭用户还是用windows好了”。
Linux没准永远都不会成为一个好的桌面操作系统，因为Unix文化所看重的那些东西本身，就妨碍了Linux成为一个面向最终用户的桌面系统。OS/X就是一个例证：Apple终于创造出了面向最终用户的Unix，唯一的原因是，Apple的工程师和领导者都坚定地以最终用户为核心，而完全放弃了Unix文化中最基本的“以程序员为核心”的理念。他们甚至把Unix的核心目录改名了——“bin”和”lib”变成了对一般用户来说更通俗易懂的”application”和”library”。
原文最后一段说得也很好……既然是结尾了，就偷偷懒，原文照抄：
There are too many monocultural programmers who, like the typical American kid who never left St. Paul, Minnesota, can't quite tell the difference between a cultural value and a core human value. I've encountered too many Unix programmers who sneer at Windows programming, thinking that Windows is heathen and stupid. Raymond all too frequently falls into the trap of disparaging the values of other cultures without considering where they came from. It's rather rare to find such bigotry among Windows programmers, who are, on the whole, solution-oriented and non-ideological. At the very least, Windows programmers will concede the faults of their culture and say pragmatically, "Look, if you want to sell a word processor to a lot of people, it has to run on their computers, and if that means we use the Evil Registry instead of elegant ~/.rc files to store our settings, so be it." The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here") stems from a culture that feels itself under siege, unable to break out of the server closet and hobbyist market and onto the mainstream desktop. This haughtiness-from-a-position-of-weakness is the biggest flaw of <>, but it's not really a big flaw: on the whole, the book is so full of incredibly interesting insight into so many aspects of programming that I'm willing to hold my nose during the rare smelly ideological rants because there's so much to learn about universal ideals from the rest of the book. Indeed I would recommend this book to developers of any culture in any platform with any goals, because so many of the values which it trumpets are universal. 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.
Google 翻译
2003 年 12 月 14 日，乔尔·斯波斯基 作者 JOEL SPOLSKY
到目前为止，Windows 和 Unix 在功能上的相似之处多于不同之处。它们都支持相同的主要编程隐喻，从命令行到 GUI 再到 Web 服务器；它们围绕几乎相同的系统资源进行组织，从几乎相同的文件系统到内存，再到套接字、进程和线程。没有太多关于每个操作系统提供的核心服务集来限制您可以创建的应用程序的种类。
剩下的就是文化差异了。是的，我们都吃食物，但在那边，他们用木棍吃生鱼配米饭，而在这边，我们用手吃面包上的牛碎。文化差异并不意味着美国人的胃不能消化寿司或日本的胃不能消化巨无霸，也不意味着没有很多美国人吃寿司或日本人吃汉堡，但是这确实意味着第一次在东京下飞机的美国人会面临一种压倒性的感觉，即这个地方很奇怪，该死的，而且没有多少哲学思考我们是如何在下面是一样的，我们都爱和工作并且唱歌和死亡将克服美国人和日本人永远无法真正熟悉彼此的厕所安排。
Unix 和 Windows 程序员之间的文化差异是什么？有很多细节和微妙之处，但在很大程度上归结为一件事：Unix 文化重视对其他程序员有用的代码，而 Windows 文化重视对非程序员有用的代码。
当然，这是一个主要的简化，但实际上，这是一个很大的区别：我们是为程序员还是为最终用户编程？其他一切都是评论。
经常引起争议的埃里克·S·雷蒙德 (Eric S. Raymond) 刚刚写了一本关于 Unix 编程的长篇巨著，名为The Art of UNIX Programming，非常详细地探索了他自己的文化。您可以购买这本书并在纸质版上阅读，或者，如果雷蒙德的政治过于反智主义以至于您无法考虑给他钱，您甚至可以在线免费阅读，并且放心，作者不会收到一分钱他的辛勤工作。
让我们看一个小例子。Unix 编程文化在可以从命令行调用的程序中享有很高的声誉，这些程序采用控制其行为各个方面的参数，其输出可以捕获为规则格式的机器可读纯文本。这样的程序很有价值，因为它们可以很容易地被程序员合并到其他程序或更大的软件系统中。举一个微小的例子，在 Unix 文化中有一个核心价值观，Raymond 称之为“沉默是金”，即一个完全按照您的要求成功完成的程序应该不提供任何输出. 无论您只是输入了 300 个字符的命令行来创建文件系统，还是构建并安装了复杂的软件，或者将载人火箭送上了月球，都没有关系。如果成功，可接受的做法就是不输出任何内容。用户将从下一个命令提示符推断一切都必须正常。
这是 Unix 文化中的一个重要价值，因为你是在为其他程序员编程。正如 Raymond 所说，“喋喋不休的程序往往不能与其他程序很好地协同工作。” 相比之下，在 Windows 文化中，您正在为 Marge Aunt 编程，而 Marge Aunt 可能有理由观察到一个因为成功而没有输出的程序无法与一个因为严重失败或失败而没有产生输出的程序区分开来。程序没有产生输出，因为它误解了您的请求。
同样，Unix 文化欣赏保持文本的程序。他们不太喜欢 GUI，除了像在文本程序上干净地涂上口红一样，而且他们不喜欢二进制文件格式。这是因为文本界面比 GUI 界面更容易编程，GUI 界面几乎不可能编程，除非做出一些其他规定，如内置脚本语言。在这里，我们再次看到 Unix 文化重视创建对其他程序员有用的代码，这在 Windows 编程中很少是目标。
这并不是说所有的 Unix 程序都是专门为程序员设计的。离得很远。但是文化重视对程序员有用的东西，这就解释了一两件事。
假设您让一名 Unix 程序员和一名 Windows 程序员分别给他们创建相同的最终用户应用程序的任务。Unix 程序员将创建一个命令行或文本驱动的核心，偶尔，作为事后的想法，构建一个驱动该核心的 GUI。这样，应用程序的主要操作将可供其他程序员使用，他们可以在命令行上调用该程序并以文本形式读取结果。Windows 程序员倾向于从 GUI 开始，偶尔，作为事后的想法，添加可以自动操作 GUI 界面的脚本语言。这适用于一种文化，在这种文化中，99.999% 的用户在任何方面、形式或形式上都不是程序员，并且没有兴趣成为程序员。
有一大群主要为其他程序员编写代码的 Windows 程序员：Microsoft 内部的 Windows 团队本身。他们倾向于做事的方式是创建一个 API，可从 C 语言调用，实现功能，然后创建调用该 API 的 GUI 应用程序。您可以从 Windows 用户界面执行的任何操作也可以使用可从任何合理的编程语言调用的编程接口来完成。例如，Microsoft Internet Explorer 本身不过是一个 89 KB 的小程序，它包含了几十个非常强大的组件，这些组件可以免费提供给经验丰富的 Windows 程序员，并且它们大多被设计为灵活而强大。不幸的是，由于程序员无法访问这些组件的源代码，它们只能以 Microsoft 组件开发人员精确预见和允许的方式使用，这并不总是奏效。有时会出现错误，通常是调用 API 的人的错误，没有源代码很难或不可能调试这些错误。Unix的文化价值可见的源代码使其成为更容易开发的环境。任何 Windows 开发人员都会告诉您他们花了四天的时间来追踪错误，因为他们认为 LocalSize 返回的内存大小与他们最初使用 LocalAlloc 请求的内存大小相同，或者他们可以使用的一些类似错误如果他们能看到图书馆的源代码，他们会在十分钟内修好。Raymond 发明了一个有趣的故事来说明这一点，这对任何曾经使用过二进制形式的库的人来说都是真实的。
所以你得到了这些宗教争论。Unix 更好，因为您可以调试到库中。Windows 更好，因为 Marge 阿姨得到一些确认，确认她的电子邮件确实已发送。实际上，一个并不比另一个好，它们只是具有不同的价值观：在 Unix 中，让其他程序员的事情变得更好是一个核心价值，而在 Windows 中，让事情变得更好是 Marge 阿姨的核心价值。
让我们再看看另一个文化差异。雷蒙德说，“经典的 Unix 文档被写成电报式的但完整的……这种风格假设一个活跃的读者，一个能够从所说的内容中推断出明显未说的后果，并且有信心相信这些推论的人。仔细阅读每一个字，因为你很少会被告知两次。” 哦，我想，他实际上是在教年轻的程序员写更多不可能的手册页。
对于最终用户，您永远无法摆脱这一点。Raymond 可能称之为“过于简单化的居高临下”，但 Windows 文化明白最终用户不喜欢阅读，如果他们同意阅读您的文档，他们只会阅读最少的内容，因此您必须反复解释……确实一个好的 Windows 帮助文件的标志是任何一个主题都可以被普通读者自己阅读，而无需假定了解任何其他帮助主题。
我们如何获得不同的核心价值观？这是 Raymond 的书如此出色的另一个原因：他深入探讨了 Unix 的历史和演变，并让新程序员快速了解 1969 年以来积累的所有文化历史。Unix 何时创建，何时形成其文化价值,没有最终用户. 计算机很贵，CPU 时间很贵，学习计算机意味着学习如何编程。难怪出现的文化重视对其他程序员有用的东西。相比之下，Windows 的创建只有一个目标：销售尽可能多的副本以获利。大量的副本。“每个桌面和每个家庭中都有一台计算机”是创建 Windows、设置其议程并确定其核心价值的团队的明确目标。非程序员的易用性是进入每张办公桌和每个家庭的唯一途径，因此可用性 über alles 成为文化规范。程序员，作为观众，是极端事后才想到的。
文化分裂是如此尖锐，以至于 Unix 从未真正在桌面上取得任何进展。Marge Aunt 不能真正使用 Unix，并且多次努力为 Unix 制作一个 Marge Aunt可以使用的漂亮前端都失败了，完全是因为这些努力是由沉浸在 Unix 文化中的程序员完成的。例如，Unix 具有将策略与机制分离的价值，这在历史上来自X的设计者。这直接导致了用户界面的分裂；没有人能够就桌面 UI 应该如何工作的所有细节达成一致，他们认为这没问题，因为他们的文化重视这种多样性，但对于 Marge 阿姨来说，这非常不可以在一个程序中使用与在另一个程序中使用不同的 UI 来剪切和粘贴。所以我们到了，在 Unix 开发人员开始尝试在他们的系统上绘制一个好的用户界面 20 年后，我们仍然处于最大 Linux 供应商的首席执行官告诉人们家庭用户应该只使用 Windows 的地步. 我听说经济学家声称，硅谷永远不可能在法国等地重现，因为法国文化对失败的惩罚如此之高，以至于企业家不愿意冒险。也许 Linux 也是如此：它可能永远不会成为桌面操作系统，因为文化重视阻止它的东西。OS X 就是证明：Apple 最终为 Marge 阿姨创造了 Unix，但这只是因为 Apple 的工程师和经理们坚定地支持最终用户文化（我一直帝国主义地称之为“Windows 文化”，尽管历史上它起源于苹果）。他们拒绝了 Unix 文化以程序员为中心的基本规范。他们甚至重命名了核心目录——异端！— 使用常见的英语单词，如“applications”和“library”，而不是“bin”和“lib”。
Raymond 确实试图将 Unix 与其他操作系统进行比较和对比，这确实是这本优秀书籍中最薄弱的部分，因为他真的不知道自己在说什么。每当他谈到 Windows 时，他都倾向于表明他的 Windows 编程知识主要来自阅读报纸，而不是来自实际的 Windows 编程。没关系; 他不是 Windows 程序员；我们会原谅的。作为对一种文化有深入了解的人的典型特征，他知道他的文化价值观是什么，但不太注意他的文化中普遍存在的部分（杀死老太太，程序崩溃：总是很糟糕）和部分文化之间的区别。只有当你为程序员编程时才适用的文化（吃生鱼，命令行参数：取决于观众）。
有太多的单一文化程序员，就像从未离开过明尼苏达州圣保罗的典型美国孩子一样，不能完全区分文化价值观和核心人类价值观之间的区别。我遇到过太多嘲笑 Windows 编程的 Unix 程序员，认为 Windows 是异教徒和愚蠢的。雷蒙德经常陷入贬低其他文化价值观而不考虑它们来自何处的陷阱。在 Windows 程序员中很少发现这样的偏执，他们总体上是面向解决方案且非意识形态的。至少，Windows 程序员会承认他们文化的缺陷并务实地说，“看，如果你想向很多人销售文字处理器，它必须在他们的计算机上运行，如果这意味着我们使用邪恶的注册表而不是优雅的 ~/. rc 文件来存储我们的设置，就这样吧。” 事实上，Unix 世界充满了自以为是的文化优势、“鼓吹”和 slashdot-karma-whoring 宗派主义，而 Windows 世界则更加务实（“是的，无论如何，我只需要在这里谋生” ) 源于一种感觉自己被围困的文化，无法突破服务器机柜和爱好者市场并进入主流桌面。这种弱势地位的傲慢是最大的缺陷 无法突破服务器柜和爱好者市场并进入主流桌面。这种弱势地位的傲慢是最大的缺陷 无法突破服务器柜和爱好者市场并进入主流桌面。这种弱势地位的傲慢是最大的缺陷The Art of UNIX Programming，但这并不是什么大缺陷：总的来说，这本书对编程的许多方面都充满了令人难以置信的有趣见解，以至于我愿意在罕见的臭臭的意识形态咆哮中屏住鼻子，因为有从本书的其余部分可以学到很多关于普遍理想的知识。事实上，我会向任何目标的任何平台上的任何文化的开发人员推荐这本书，因为它所宣扬的许多价值观都是普遍的。当 Raymond指出CSV 格式不如 /etc/passwd 格式时，他试图为 Unix 和 Windows 打分，但是，你知道吗？他是对的。/etc/passwd比 CSV更容易解析，如果你读过这本书，你就会知道为什么，你会成为一个更好的程序员。
英文原文
DECEMBER 14, 2003 by JOEL SPOLSKY
By now, Windows and Unix are functionally more similar than different. They both support the same major programming metaphors, from command lines to GUIs to web servers; they are organized around virtually the same panoply of system resources, from nearly identical file systems to memory to sockets and processes and threads. There’s not much about the core set of services provided by each operating system to limit the kinds of applications you can create.
What’s left is cultural differences. Yes, we all eat food, but over there, they eat raw fish with rice using wood sticks, while over here, we eat slabs of ground cow on bread with our hands. A cultural difference doesn’t mean that American stomachs can’t digest sushi or that Japanese stomachs can’t digest Big Macs, and it doesn’t mean that there aren’t lots of Americans who eat sushi or Japanese who eat burgers, but it does mean that Americans getting off the plane for the first time in Tokyo are confronted with an overwhelming feeling that this place is strange, dammit, and no amount of philosophizing about how underneath we’re all the same, we all love and work and sing and die will overcome the fact that Americans and Japanese can never really get comfortable with each others’ toilet arrangements.
What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers.
This is, of course, a major simplification, but really, that’s the big difference: are we programming for programmers or end users? Everything else is commentary.
The frequently controversial Eric S. Raymond has just written a long book about Unix programming called The Art of UNIX Programming exploring his own culture in great detail. You can buy the book and read it on paper, or, if Raymond’s politics are just too anti-idiotarian for you to consider giving him money, you can even read it online for free and rest assured that the author will not receive a penny for his hard work.
Let’s look at a small example. The Unix programming culture holds in high esteem programs which can be called from the command line, which take arguments that control every aspect of their behavior, and the output of which can be captured as regularly-formatted, machine readable plain text. Such programs are valued because they can easily be incorporated into other programs or larger software systems by programmers. To take one miniscule example, there is a core value in the Unix culture, which Raymond calls “Silence is Golden,” that a program that has done exactly what you told it to do successfully should provide no output whatsoever. It doesn’t matter if you’ve just typed a 300 character command line to create a file system, or built and installed a complicated piece of software, or sent a manned rocket to the moon. If it succeeds, the accepted thing to do is simply output nothing. The user will infer from the next command prompt that everything must be OK.
This is an important value in Unix culture because you’re programming for other programmers. As Raymond puts it, “Programs that babble don’t tend to play well with other programs.” By contrast, in the Windows culture, you’re programming for Aunt Marge, and Aunt Marge might be justified in observing that a program that produces no output because it succeeded cannot be distinguished from a program that produced no output because it failed badly or a program that produced no output because it misinterpreted your request.
Similarly, the Unix culture appreciates programs that stay textual. They don’t like GUIs much, except as lipstick painted cleanly on top of textual programs, and they don’t like binary file formats. This is because a textual interface is easier to program against than, say, a GUI interface, which is almost impossible to program against unless some other provisions are made, like a built-in scripting language. Here again, we see that the Unix culture values creating code that is useful to other programmers, something which is rarely a goal in Windows programming.
Which is not to say that all Unix programs are designed solely for programmers. Far from it. But the culture values things that are useful to programmers, and this explains a thing or two about a thing or two.
Suppose you take a Unix programmer and a Windows programmer and give them each the task of creating the same end-user application. The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core. This way the main operations of the application will be available to other programmers who can invoke the program on the command line and read the results as text. The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface. This is appropriate for a culture in which 99.999% of the users are not programmers in any way, shape, or form, and have no interest in being one.
There is one significant group of Windows programmers who are primarily coding for other programmers: the Windows team itself, inside Microsoft. The way they tend to do things is to create an API, callable from the C language, which implements the functionality, and then create GUI applications which call that API. Anything you can do from the Windows user interface can also be accomplished using a programming interface callable from any reasonable programming language. For example, Microsoft Internet Explorer itself is nothing but a tiny 89 KB program which wraps together dozens of very powerful components which are freely available to sophisticated Windows programmers and which are mostly designed to be flexible and powerful. Unfortunately, since programmers do not have access to the source code for those components, they can only be used in ways which were precisely foreseen and allowed for by the component developers at Microsoft, which doesn’t always work out. And sometimes there are bugs, usually the fault of the person calling the API, which are difficult or impossible to debug without the source code. The Unix cultural value of visible source code makes it an easier environment to develop for. Any Windows developer will tell you about the time they spent four days tracking down a bug because, say, they thought that the memory size returned by LocalSize would be the same as the memory size they originally requested with LocalAlloc, or some similar bug they could have fixed in ten minutes if they could see the source code of the library. Raymond invents an amusing story to illustrate this which will ring true to anyone who has ever used a library in binary form.
So you get these religious arguments. Unix is better because you can debug into libraries. Windows is better because Aunt Marge gets some confirmation that her email was actually sent. Actually, one is not better than another, they simply have different values: in Unix making things better for other programmers is a core value and in Windows making things better for Aunt Marge is a core value.
Let’s look at another cultural difference. Raymond says, “Classic Unix documentation is written to be telegraphic but complete… The style assumes an active reader, one who is able to deduce obvious unsaid consequences of what is said, and who has the self-confidence to trust those deductions. Read every word carefully, because you will seldom be told anything twice.” Oy vey, I thought, he’s actually teaching young programmers to write more impossible man pages.
For end users, you’ll never get away with this. Raymond may call it “oversimplifying condescension,” but the Windows culture understands that end users don’t like reading and if they concede to read your documentation, they will only read the minimum amount, and so you have to explain things repeatedly… indeed the hallmark of a good Windows help file is that any single topic can be read by itself by an average reader without assuming knowledge of any other help topic.
How did we get different core values? This is another reason Raymond’s book is so good: he goes deeply into the history and evolution of Unix and brings new programmers up to speed with all the accumulated history of the culture back to 1969. When Unix was created and when it formed its cultural values, there were no end users. Computers were expensive, CPU time was expensive, and learning about computers meant learning how to program. It’s no wonder that the culture which emerged valued things which are useful to other programmers. By contrast, Windows was created with one goal only: to sell as many copies as conceivable at a profit. Scrillions of copies. “A computer on every desktop and in every home” was the explicit goal of the team which created Windows, set its agenda and determined its core values. Ease of use for non-programmers was the only way to get on every desk and in every home and thus usability über alles became the cultural norm. Programmers, as an audience, were an extreme afterthought.
The cultural schism is so sharp that Unix has never really made any inroads on the desktop. Aunt Marge can’t really use Unix, and repeated efforts to make a pretty front end for Unix that Aunt Marge can use have failed, entirely because these efforts were done by programmers who were steeped in the Unix culture. For example, Unix has a value of separating policy from mechanism which, historically, came from the designers of X. This directly led to a schism in user interfaces; nobody has ever quite been able to agree on all the details of how the desktop UI should work, and they think this is OK, because their culture values this diversity, but for Aunt Marge it is very much not OK to have to use a different UI to cut and paste in one program than she uses in another. So here we are, 20 years after Unix developers started trying to paint a good user interface on their systems, and we’re still at the point where the CEO of the biggest Linux vendor is telling people that home users should just use Windows. I have heard economists claim that Silicon Valley could never be recreated in, say, France, because the French culture puts such a high penalty on failure that entrepreneurs are not willing to risk it. Maybe the same thing is true of Linux: it may never be a desktop operating system because the culture values things which prevent it. OS X is the proof: Apple finally created Unix for Aunt Marge, but only because the engineers and managers at Apple were firmly of the end-user culture (which I’ve been imperialistically calling “the Windows Culture” even though historically it originated at Apple). They rejected the Unix culture’s fundamental norm of programmer-centricity. They even renamed core directories — heretical! — to use common English words like “applications” and “library” instead of “bin” and “lib.”
Raymond does attempt to compare and contrast Unix to other operating systems, and this is really the weakest part of an otherwise excellent book, because he really doesn’t know what he’s talking about. Whenever he opens his mouth about Windows he tends to show that his knowledge of Windows programming comes mostly from reading newspapers, not from actual Windows programming. That’s OK; he’s not a Windows programmer; we’ll forgive that. As is typical from someone with a deep knowledge of one culture, he knows what his culture values but doesn’t quite notice the distinction between parts of his culture which are universal (killing old ladies, programs which crash: always bad) and parts of the culture which only apply when you’re programming for programmers (eating raw fish, command line arguments: depends on audience).
There are too many monocultural programmers who, like the typical American kid who never left St. Paul, Minnesota, can’t quite tell the difference between a cultural value and a core human value. I’ve encountered too many Unix programmers who sneer at Windows programming, thinking that Windows is heathen and stupid. Raymond all too frequently falls into the trap of disparaging the values of other cultures without considering where they came from. It’s rather rare to find such bigotry among Windows programmers, who are, on the whole, solution-oriented and non-ideological. At the very least, Windows programmers will concede the faults of their culture and say pragmatically, “Look, if you want to sell a word processor to a lot of people, it has to run on their computers, and if that means we use the Evil Registry instead of elegant ~/.rc files to store our settings, so be it.” The very fact that the Unix world is so full of self-righteous cultural superiority, “advocacy,” and slashdot-karma-whoring sectarianism while the Windows world is more practical (“yeah, whatever, I just need to make a living here”) stems from a culture that feels itself under siege, unable to break out of the server closet and hobbyist market and onto the mainstream desktop. This haughtiness-from-a-position-of-weakness is the biggest flaw of The Art of UNIX Programming, but it’s not really a big flaw: on the whole, the book is so full of incredibly interesting insight into so many aspects of programming that I’m willing to hold my nose during the rare smelly ideological rants because there’s so much to learn about universal ideals from the rest of the book. Indeed I would recommend this book to developers of any culture in any platform with any goals, because so many of the values which it trumpets are universal. 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.