译序:
无论成功还是失败,都只是一念之间,而读者只需要体味出这些对自己过去的、手头的、未来的项目可以有何种借鉴,便已得其中三味。
序:
Unix is not so much an operating system as an oral history.
—— 与其说 Unix 是个操作系统,不如说是一部口述历史。
最简单的 Unix 设计手法就是最持久耐用的。
一。哲学:
—— Philosopy: Philosophy Matters.
Those who do not understand Unix are condemned to reinvent it,poorly.
—— 不懂 Unix 的人注定最终还要重复发明一个蹩脚的 Unix。
Unix 的一些系统级服务和应用都有类似的倾向:行为的最终逻辑被尽可能推后到使用端(比如多种 shell 和他们眼花缭乱的行为选项)。这种倾向也反映出 Unix 的遗风:原本是为技术人员设计的操作系统;同时也表明设计的信念:最终用户永远比操作系统设计人员清楚他们究竟需要什么。
只看眼前的话,Unix 的这种自由放纵主义风格会让它失去很多非技术型用户。但从长远考虑,最终你会发觉这个“错误”换来的至关重要的优势:策略相对短寿,而机制才会长存。现今流行的界面观感常常会变成明日进化的死胡同。说来说去,只提供机制不提供方针的哲学能使 Unix 长久保鲜;而那些被束缚在一套方针或界面风格内的操作系统,也许早就从人们的视线中消失了。
开源社区:既然能够改编、重用、再造,节省自己 90% 的工作量,为什么还是从零开始编码呢?
Unix 具有非常彻底的灵活性。Unix 提供众多的程序粘合手段,这意味着 Unix 基本工具箱的各种组件连纵开合后,将收到单个工具设计者无法想象的功效。
那些毫无动力、松松垮垮而且薪水微薄的程序员们,能在短短期限内,如同神灵附体般造出稳定而新颖的软件——这只不过是经理人永远的梦呓罢了。
Unix 哲学(同其它工程领域的民间传统一样)是自下而上的,而不是自上而下的。Unix 哲学注重实效,立足于丰富的经验。
让每个程序就做好一件事。如果有新任务,就重新开始,不要往原程序中加入新功能而搞得复杂。
假定每个程序的输出都会成为另一个程序的输入,哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
尽可能早地将设计和编译的软件投入试用,哪怕是操作系统也不例外,理想情况下,应该是在几个星期内。对拙劣的代码别犹豫,扔掉重写。
优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事,必先利其器。
Unix 哲学是这样的:一个程序只做一件事,并做好。程序要能协作。程序要能处理文本流,因为这是最通用的接口。
原则1:你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方,所以别急于胡乱找个地方改代码,除非你已经证实那儿就是瓶颈所在。
原则2:估量。在你没对代码进行估量,特别是没找到最耗时的那部分之前,别去优化速度。
原则3:花哨的算法比简单的算法更容易出 bug,更难实现。尽量使用简单的算法配合简单的数据结构。
原则5:数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条,正确的算法也就不言自明。编程的核心是数据结构,而不是算法。
原则6:没有原则6。
Unix 哲学从总体上说,可以概括为以下几点:
1。模块原则:使用简洁的接口拼合简单的部件。
2。清晰原则:清晰胜于机巧。
3。组合原则:设计时考虑拼接组合(你的程序不一定只是单独使用,要考虑其它程序可能会对你的程序进行组合使用)。
4。分离原则:策略同机制分离,接口同引擎分离。
5。简洁原则:设计要简洁,复杂度能低则低。
6。吝啬原则:除非确无它法,不要编写庞大的程序。
7。透明性原则:设计要可见,以便审查和调试。
8。健壮原则:健壮源于透明与简洁。
9。表示原则:把知识叠入数据以求逻辑质朴而健壮。
10。通俗原则:接口设计避免标新立异。
11。缄默原则:如果一个程序没什么好说的,就沉默。
12。补救原则:出现异常时,马上退出并给出足够的错误信息。
13。经济原则:宁花机器一分,不花程序员一秒。
14。生成原则:避免手工 hack ,尽量编写程序去生成程序。
15。优化原则:雕琢前先要有原型,跑之前先学会走。
16。多样原则:决不相信所谓的“不二法门”的断言。
17。扩展原则:设计着眼未来,未来总比预想来得快。
转载请标明出处:
http://kyo-cc.iteye.com/
无论成功还是失败,都只是一念之间,而读者只需要体味出这些对自己过去的、手头的、未来的项目可以有何种借鉴,便已得其中三味。
序:
Unix is not so much an operating system as an oral history.
—— 与其说 Unix 是个操作系统,不如说是一部口述历史。
最简单的 Unix 设计手法就是最持久耐用的。
一。哲学:
—— Philosopy: Philosophy Matters.
Those who do not understand Unix are condemned to reinvent it,poorly.
—— 不懂 Unix 的人注定最终还要重复发明一个蹩脚的 Unix。
Unix 的一些系统级服务和应用都有类似的倾向:行为的最终逻辑被尽可能推后到使用端(比如多种 shell 和他们眼花缭乱的行为选项)。这种倾向也反映出 Unix 的遗风:原本是为技术人员设计的操作系统;同时也表明设计的信念:最终用户永远比操作系统设计人员清楚他们究竟需要什么。
只看眼前的话,Unix 的这种自由放纵主义风格会让它失去很多非技术型用户。但从长远考虑,最终你会发觉这个“错误”换来的至关重要的优势:策略相对短寿,而机制才会长存。现今流行的界面观感常常会变成明日进化的死胡同。说来说去,只提供机制不提供方针的哲学能使 Unix 长久保鲜;而那些被束缚在一套方针或界面风格内的操作系统,也许早就从人们的视线中消失了。
开源社区:既然能够改编、重用、再造,节省自己 90% 的工作量,为什么还是从零开始编码呢?
Unix 具有非常彻底的灵活性。Unix 提供众多的程序粘合手段,这意味着 Unix 基本工具箱的各种组件连纵开合后,将收到单个工具设计者无法想象的功效。
那些毫无动力、松松垮垮而且薪水微薄的程序员们,能在短短期限内,如同神灵附体般造出稳定而新颖的软件——这只不过是经理人永远的梦呓罢了。
Unix 哲学(同其它工程领域的民间传统一样)是自下而上的,而不是自上而下的。Unix 哲学注重实效,立足于丰富的经验。
让每个程序就做好一件事。如果有新任务,就重新开始,不要往原程序中加入新功能而搞得复杂。
假定每个程序的输出都会成为另一个程序的输入,哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
尽可能早地将设计和编译的软件投入试用,哪怕是操作系统也不例外,理想情况下,应该是在几个星期内。对拙劣的代码别犹豫,扔掉重写。
优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事,必先利其器。
Unix 哲学是这样的:一个程序只做一件事,并做好。程序要能协作。程序要能处理文本流,因为这是最通用的接口。
原则1:你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方,所以别急于胡乱找个地方改代码,除非你已经证实那儿就是瓶颈所在。
原则2:估量。在你没对代码进行估量,特别是没找到最耗时的那部分之前,别去优化速度。
原则3:花哨的算法比简单的算法更容易出 bug,更难实现。尽量使用简单的算法配合简单的数据结构。
原则5:数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条,正确的算法也就不言自明。编程的核心是数据结构,而不是算法。
原则6:没有原则6。
Unix 哲学从总体上说,可以概括为以下几点:
1。模块原则:使用简洁的接口拼合简单的部件。
2。清晰原则:清晰胜于机巧。
3。组合原则:设计时考虑拼接组合(你的程序不一定只是单独使用,要考虑其它程序可能会对你的程序进行组合使用)。
4。分离原则:策略同机制分离,接口同引擎分离。
5。简洁原则:设计要简洁,复杂度能低则低。
6。吝啬原则:除非确无它法,不要编写庞大的程序。
7。透明性原则:设计要可见,以便审查和调试。
8。健壮原则:健壮源于透明与简洁。
9。表示原则:把知识叠入数据以求逻辑质朴而健壮。
10。通俗原则:接口设计避免标新立异。
11。缄默原则:如果一个程序没什么好说的,就沉默。
12。补救原则:出现异常时,马上退出并给出足够的错误信息。
13。经济原则:宁花机器一分,不花程序员一秒。
14。生成原则:避免手工 hack ,尽量编写程序去生成程序。
15。优化原则:雕琢前先要有原型,跑之前先学会走。
16。多样原则:决不相信所谓的“不二法门”的断言。
17。扩展原则:设计着眼未来,未来总比预想来得快。
转载请标明出处:
http://kyo-cc.iteye.com/