UNIX编程艺术经典读后感有感
《UNIX编程艺术》是一本由Eric S. Raymond著作，电子工业出版社出版的530图书，本书定价：69.00元，页数：2011-1，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《UNIX编程艺术》精选点评：
●人文类书籍。。
●挺有意思的，特别是关于简洁、OO、接口的讨论，值得一读！
●大牛作品,值得一读...说是编程,实际基本没代码在里面,主要介绍编程哲学,不过很受用.
●有太多的unix小技巧。很多程序如果之前没有用过或者了解过的话，读起来不是很容易懂。不过其中的Unix哲学确实收益匪浅。DRY（SPOT），KISS，接口引擎分离，代码要保持透明与简洁等等。如果对Unix的各种程序了解的很多，这本书真心会读着很有收获。想想前半本是大概3年前读的，那时候很多地方没看懂，是不是得再看一遍。坑爹，所有书都想再看一遍自己也是醉了~~
●读了一半。感觉实在是太老了，有点过时
●翻译的不太好，有些看不懂，有空再反复读
●介绍了Unix的历史和文化，很多理念已经知道了，但是还有更多不清楚，所以算是好好科普了一把，由于自己也不是很熟悉Linux/Unix，所以书中的许多举例都不散很清楚，读的也比较快。
●这个是新翻译的版本 还是只重新印刷的？见鬼
●部分翻译太屎了
●最爱 八卦什么的了
《UNIX编程艺术》读后感(一)：关于程序设计的一本哲学书
这本书已经不是一本技术书，已经深深阐述到哲学层面了，很多次抑制不住想读它的冲动，每次去读，都失望而归，因为其中语言容易理解，意境却很难参透。随着工作经验的增长，偶尔有人推荐，还是回去读它，终于逐渐读懂了一点点。
《UNIX编程艺术》读后感(二)：翻译的水平真是........
读起来真是费劲，特别是第18章，没几句话是通顺的，哎.....糟蹋这书了
我的评论太短了？
还让我咋评呢？推荐看英文原版的，看着会舒服些
还太短了？
豆瓣啊豆瓣
读起来真是费劲，特别是第18章，没几句话是通顺的，哎.....糟蹋这书了
我的评论太短了？
还让我咋评呢？推荐看英文原版的，看着会舒服些
还太短了？
豆瓣啊豆瓣
《UNIX编程艺术》读后感(三)：这本书可以
我想学编程，可是每次买一本书，刚开始翻的时候信心十足，翻着翻着，信心就一点点往下减。真是看得要累晕掉了。这本书又这样了，听说是属于编程经典一类的，刚买来挺高兴的。就怕自己坚持不了几天。昨天我哥在网上找到一个猎豹网校，让我看一下。你别说，正好有我要学的这门课，打开看老师讲的视频，跟看电影似的，那比自己啃书当然要轻松好多啊！而且，有了问题能找到老师请教，老师会耐心解答，我觉得这下应该能坚持学下去了！
《UNIX编程艺术》读后感(四)：ESR这个Unix死忠
原著成书于2003年，而且作者说写了5年。从2003到现在2011已经又8年了，许多事情又变化了。。。
这本书在学校就读过，但当时也就是读过一遍，略微记住几个名词而已，比如KISS和文本化，现在回想下，这两个概念对自己影响确实蛮深的，当初没有白读。最初阅读时，好多软件都没有接触过，也谈不上写过多少代码，书中好多东西也就那么过眼了一遍而已，在把书还给图书馆时就嘱咐自己将来一定要再读。
现在不一样了，离开学校从事软件开发实践也两年多了，很多工具都用过了，也有了新的认识，也仍有不少工具尚未接触。正好上半年部门组织读书，就推荐购买了这本2011年版的，工作闲暇加上昨天下雨不愿出门又看了一遍。
译者说作者是美国愤青，应该说是Unix愤青、Unix死忠，很多地方偏激了点或者教条了点，真应该到unix以外的世界走走。当然作者毕竟大师级明白人，20.3节中把Unix的问题都数落了一遍。毕竟unix基本已死，就是承继其衣钵的Linux占有率也就1个百分点，另一个亲戚MaxOS X和iOS日益兴隆8个点了。
有人批评作者老高抬自己的fetchmail，哈哈，这个嘛，罗马城不是一个人建成的，你不能期盼作者什么都懂。我在看书也老联想自己开发的那几个小工具，给别人举例也爱提它们。毕竟作者对fetchmail知根知底啊，如果作者举个不太熟悉的例子万一说错了岂不招来更大的争议。
1.6节那17个原则全部值得牢记于心，如若真的记不住全部，那就记住KISS这个单词吧，若不满足一个词那就再来句David Gelernter的话——美是抵御复杂的终极武器。什么是美？清晰、简单、真相、省力，这就是Unix哲学的全部。
说说03年到现在变化的东西吧：
1、OOXML继ODF后成为了最新的国际文档标准，这是XML格式和“文本+压缩”解决方案的重大成果。除了XML，更美的json也是有标准的。
2、版本管理工具方面：svn已成最广泛使用的准工业标准工具；Linus开发了Git取代了BitKeeper用来管理linux源代码，而且以Git为老大Mercurial和bazaar等垫后的DVS已大有替代svn之势。
3、语言方面。javaｓｃｒｉｐｔ日益光鲜，Python更加强大，Ruby的吸引力也还算不错，但还是作者345页评论的“似乎很有前途”。另外Lua作为可嵌入语言崛起了，Object C背靠MacOS X和iOS攻城掠地。google都推出了Go语言，不能怪作者独守unix一隅，只能说这个世界变化太快。
再批评下作者吧：
4、编辑器和IDE方面。你就用下IDE会死啊？Eclipse、NetBeans和Visual Studio等。大工程还得靠IDE来提高生产力。
5、产品要大卖，还得靠大方漂亮的GUI。
----------补充一些写作、翻译和印刷遗憾-----------
1、中文目录1.6.2和1.6.4的章节标题中冒号是半角的吧，而其他15个标题都是全角的。
2、420也最后一行那个是C1I还是ClI，下次记得印刷成CLI。
3、308页13.2.4节最后一句话，维->难。
4、470也说C语言是弱类型语言，这个翻译错误太大了。
《UNIX编程艺术》读后感(五)：《The Art of UNIX Programming》阅读感受
花了3个小时将书翻了一下，摘录一下比较好的内容。
基本大多数最有价值的想法都在第一章（哲学）中进行了说明。
---
gt; UNIX的哲学是这样的：一个程序只做一件事，并做好，程序要能协作。程序要能处理文本流，因为这是最通用的接口。
确实是无所不在的**KISS**，UNIX的哲学在于，每次只做好一件事情，然后通过一个个小而正交的工具/API/程序进行组合来得到更加强大的功能（如同书中说的，UNIX负责提供机制，而策略是使用者决定的，Happy Hacking!）
gt; 花哨的算法在n很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨的算法。
gt; 花哨算法比简单算法更容易出bug，更难实现。尽量使用简单的算法配合简单的数据结构
gt; 过早优化是万恶之源
还有一个「更狠」的描述：
gt; 拿不准就穷举。
核心意义就在于：**尽量的保持简单，不要过早的优化**，除非你知道确实需要优化，以及需要优化的地方。
gt; 经济原则：宁花机器一分，不花程序员一秒。
有时候优化的效果还跑不赢：1）加内存条 2）摩尔定律导致的性能提升。。。。。
gt; 计算机编程的本质就是控制复杂度。
gt; 为了取得程序一丁点的性能提升就大幅度增加技术的复杂性和晦涩性，这个买卖做不得——这不仅仅是因为复杂的代码更容易滋生bug，也因为它会使日后的阅读和维护工作更加艰难。
gt; 清晰原则：清晰胜于机巧。
还是KISS，清新，简洁，简单才是构架大型系统（或者是复杂度极高）系统应该遵循的__最高原则__。
所以总的说来，LINUX的哲学就是：
1. KISS
2. 提供机制，不提供策略。
就是因为这样子的哲学，才会让UNIX设计出统一的I/O系统模型，管道，和强大的IPC等各种机制吧。
---
但是更大的哲学应该是「和谐」，这个世界上没有绝对正确的设计标准，至少在软件开发领域是没有银弹的。
比如说，提供小而精的工具套就一定比提供大而全的系统要好嘛？我觉得也不一定吧。提供太多的选择反而有时候反而会让用户搞不清楚到底使用什么？
而相反，提供一个「权威甚至唯一」的工具，或者是无脑式的「一路next」封装至少对于大多数用户的大多数应用而言就足够了，这也就是为什么
windows占据怎么多年应用市场的原因吧。毕竟并不是所有的人都非常乐意去「hacking」和「customizatin」。
所以总的说来，UNIX/LINUX的设计哲学对于一个**开发人员**是非常有参考和实践价值的。
然后，我也是一个坚定的KISS实践者。
gt; Two Answers:
gt;1. What is the best thing about UNIX？
gt;A: The community.
gt;2. What is the worst thing about UNIX？
gt;A: That there are so many communities.