最近，我看完了Peter Seibel的《编程人生》。哈，这是一本世界顶尖程序员和计算机科学家的访谈。看看都有谁，这些牛人在Wiki上都有自己的条目：Jamie Zawinski、Brad Fitzpatrick、Douglas Crockford、Brendan Eich、Josh Bloch、Joe Armstrong、Simon Peyton-Jones、Peter Norvig、Guy Steele、Dan Ingalls、Peter Deutsch、Ken Thompson、Fran Allen、Bernie Cosell和Don Knuth。
这本书固然非常棒，我非常喜欢，不过囿于访谈这种体裁，比较被采访人关于相同话题的观点也确实有点麻烦。但不管怎么说，作者Peter Seibel还是忠实地记录了他们的言论，所以我就想自己从这些智慧箴言中再提炼出一些真正有用的观点来。
经过一番努力，我按照自己的兴趣（静态类型和不变量）分别挑选出了一些重要的话。我这种分法未必合理，供大家参考吧。

图灵既然引进了这本书，为什么不引进《Founders at Work: Stories of Startups' Early Days (Recipes: a Problem-Solution Ap)》by Jessica Livingston呢？都是同一个Apress出版社的，我在Amazon上一搜“Coders at Work”就出来，而且看起来更畅销些！

大牛们谈“静态类型”
Brad Fitzpatrick：“我也希望能够在编译时得到一些警示，希望它能提醒我‘你看看，你这都干了些什么呀’之类的。而有时候呢，我又觉得无所谓，希望在运行时再被曝光问题或者什么的。”
Doug Crockford：“可是你在经典继承当中做不到这一点——你只能一味地按照抽象到实例的思维方式 去想。在这个思想框架中，很难设计出合理的层次关系。等后来你真的理解了问题所在之后，你就不得不再回过头来对它进行重构。这时候再重构对代码的影响可就 不是一星半点了，如果在你幡然醒悟的时候，原来的代码已经变得非常庞大了，你怎么办？”
Doug Crockford：“在JavaScript中，我发现重构真是很简单的一件事。可是如果要对一个层层递进的类层次进行重构，那可就要多难有多难了。”
Brendan Eich：“那些疯疯颠颠、几近白痴的话不能信，说什么动态语言终有一天会完全把Java还有静态语言取而代之，这不是混话吗？”
Josh Bloch：“OO很有意思。可以从两方面看，首先就是模块化。模块化很了不起啊。不过，我倒不觉得这是OO的人的专利。……其次就是继承，而我对继承的看法跟现在很多人的看法一样，那就是继承有利也有弊。”
Josh Bloch：“这个例子就说明，必须要有安全的语言。这个问题（栈溢出）本来就不是人应该考虑的事。”
Josh Bloch：“我还是喜欢泛型。泛型可以帮我找出代码中的bug，可以让我把通常得写在注释里面的约定拿出来写在代码里面，然后通过编译器来保证它们得到强制遵守。”
Joe Armstrong：“然后支持静态类型的人就说了，‘好，在封送数据结构的时候我们的的确确能感受到动态类型的好处。’如果你随便在网上发一段程序，如果你不知道数据类型，就没办法重建原来的数据。”
Joe Armatrong：“我们缺少两类东西之间的一个协议：你发给我一个那种东西，我再发给一个这种东西，怎么办？数据包以及它们的类型有多种方式可以描述，但描述协议的方式却非常有限。”
Simon Peyton-Jones：“其中一个不常提及的例子就是维护。当你面对一堆3年前写的不那么完美的代码，又想对它进行系统性地改进，怎么办？注意是系统性、全局性的改进，不是单单修改哪个例程。在这种情况下，类型系统的作用一下就显现出来了。”
Simon Peyton-Jones：“只要静态类型合适，你就尽管放心地用，光从维护角度看，你就值了。”
Dan Ingalls：“类型就相当于程序中的断言。我认为尽量保持事情简单很有价值，包括连类型都不必提。”
Ken Thompson：“有bug就有bug呗。谁写代码都会有bug，那都是人的问题。如果说它是一种运行时安全的语言，那么遇到bug时，操作系统应该崩溃，用不着什么缓冲区溢出，也就不会被利用了。”
大牛们谈“不变量和断言”
Jamie Zawinski：“显而易见，放一条断言语句进去对调试而言肯定有用，而且就像你说的，对写文档也有用。”
Brad Fitzpatrick：“我主要会在开始的时候考虑很多条件，然后在构造函数中和函数的开头再一一检查。”
Brendan Eich：“那些写得不好的断言就不提了，反正在Mozilla，随着时间推移，好的断言越来越多。由此，我们觉得也受到了一些启发，明白了什么是不变量，而这些恐怕只有在理想的类型系统中才能表达。”
Doug Crockford：“说简单点，软件其实就是一套关于软件该怎么工作的规范。任何不完整的规范，都不能告诉你软件最终会怎么实现它的功能。”
Doug Crockford：“我觉得Eiffel确实更有意思一些，我喜欢的是它的precondition/postcondition契约。我真希望自己在用的无论哪种语言能支持这个特性，遗憾的是，这个特性跟很多其他想法一样，都没有流行起来。”
Josh Bloch：“你应该知道，断言是我在Java Programming Language中第一批加入的特性，而且我也深知，这些特性永远不进入主流文化。”
Josh Bloch：“我说过，我使用断言是为了确保编译后的不变量是可以维护的。如果不变量出了问题，我觉得应该知道是什么时候出的问题。”
Simon Peyton-Jones：“你可以给一个函数写一个类似这样的一样契约：‘你给我一个大于零的参数，我再给你一个小于零的结果。’”
Simon Peyton-Jones：“假设你宣称你的目标是让一切都能通过机器检查来验证其正确性。但这句话的意思仍然还是不够明确。机器验证可以，但根据什么来验证呢？”
Simon Peyton-Jones：“我想在真正的开发中，最好还是把那些你希望程序有的属性都写下来。比 如说，‘这个阀门不能跟那个阀门一起关。这棵树应该始终保持匀称地生成。这个函数任何时候都得返回一个大于零的结果。’这些全都是规格说明书中的一小部 分，构不成一个完整的规格说明书。它们只是你希望的东西。”
Peter Norvig：“跟循环不变量一样，我始终认为它带来的问题比好处多。”
Guy Steele：“我对应该记录什么有了更深入的理解，我觉得更多地应该是数据结构，我觉得应该更多地应该是它们的不变量。”
Guy Steele：“举个例子吧，这儿有一个数组和一个整数，而这个整数应该是数组中的一个有效索引。这个关系在Java中就不容易表达。”
Dan Ingalls：“假如在程序中什么危险的事儿都允许做，那么当你坐下来进行形式验证的时候，麻烦就都来了。你想啊，每一步你都得这么考虑，‘嗯，这个有可能发生，那个有可能发生，那个也有可能发生。’”
Peter Deutsch：“我的看法还是那样，如果你把数据结构和它们的不变量弄好了，大多数代码你就自然而然知道该怎么写了。”
Peter Deutsch：“现在想一想，要想让软件去做我们想让它做的事，不能依赖断言，或者说归纳断言，而要依靠更好、更强大、更深层次的声明性语法。”
Peter Deutsch：“在我看来，把定理验证技术当作改进软件可靠性的实用技术来用，已经基本宣告失败，而这就是原因。把想要证明的那些属性都逐个地规范起来，简直是不可能的事儿。”
Don Knuth：“有人可能会说自己的程序经过验证了，而且之所以能通过验证，是因为根据某些验证器的验证，只有该程序达到了相应规范的要求。可是，验证器就没有bug吗，规范本身也难免会有bug。”
结论
这些言论恐怕都让你眼花缭乱了吧……我想，你此刻的问题一定是：你相信谁说的？（不告诉你。）这本书里还有很多有意思的话题，等着你、你，还有你去开采呢。

转自：豆瓣 作者： figure9
很早就在Amazon上看到过这本有些技术八卦性质的书，不过当时更期待的是O'Reilly的Masterminds of programming（中文译名编程之魂），毕竟我对程序设计语言更感兴趣一些，然而被其糟糕透顶的翻译（参照我之前对此书中文译版的评论）折磨了一顿 之后，我是再也不会光顾此类书籍的中文版本了，既浪费钱也浪费精力。
　　
　　不冲别的，就冲这本书后面的那三个Turing Award（Fran Allen, Ken Thompson, Don Knuth），每个自认为是程序员或者对计算机感兴趣的人就应该阅读一下此书，这三位神级的人物，基本奠定了计算机科学几乎所有方向上的基础：编译器，操 作系统，程序设计语言，算法，数据结构。
　　
　　而至于其它的interviewee，不是One-man army型的神级程序员（Jamie Zawinski，Brad Fitzpatrick，Joshua Bloch），就是某个编程语言的创始人（Guy Steele，Joe Armstrong，Brendan Eich）。至于interviewer自己，也是一个资深程序员外加Jolt Award图书的作者。这些都成为了这本书质量的保证。
　　
　　在看了这本书之后，发现它并不像我当初想象的那样是一本技术人士的八卦图书。书里面讨论的更多的是编程的习惯，对当今程序设计方法或是程序设计语言的讨论，以及这些编程大牛在成为大牛的过程中的各种经历。很多东西都值得程序员或者是有志学习计算机科学的人借鉴。
　　
　　书中给我印象最深的是第一个人物Jamie Zawinski：典型的实用主义者，老牌黑客，XEmacs和Netscape Navigator的创始人之一。他鄙视C++，认为设计模式就是一坨Crap（reverse，inverse，double-back-flip pattern，you mean a loop?），认为质量第二，进度第一；大学肄业只有高中文化程度，却被Peter Novig称为他所见过的最有天赋的程序员之一；不喜欢去修改别人的代码，认为自己推翻了重来更方便；他并没有阅读过很多计算机图书，也没有多么深厚的数 学或是算法基础，绝大多数的计算机知识是自学或者是在项目中学到的，却一点也没有妨碍他成为世界上最顶尖的程序员之一。
　　
　　所以那些动则就扯什么算法啊基础啊内功啊所谓的大牛们，请闭上你的嘴，条条大道通罗马。算法并不是编程的前提条件，数学也不会阻碍一个人成为 优秀的程序员。至少在我看来，什么算法基础内功都是唬人的玩意，多编点能用的实用的程序才是王道，当然如果你是一个pure theroist的话就当我什么都没说好了。
　　
　　比较有意思的是，书中的人物对C++的评价都是负面的，无论是自学成才的Jamie Zawinski，还是科班出身的Joe Armstrong，甚至是和Bjarne在同一个实验室工作的Ken Thompson，都认为C++是一门差劲的语言。Ken的一句话可以反映出这些大牛对C++的普遍态度：“It certaily has its good points. But by and large I think it's a bad language. It does a lot of things half well and it's just a garbage heap of ideas that are mutually exclusive.”也难怪有传言说Ken和Bjarne一直不和，就拿Bjarne的那几部大作来说，无论是C++程序设计语言，还是C++的设计与 演化里面，Bjarne感谢了Ritchie感谢了Kernighan感谢了McIllory，却从来没有提到过Ken。
　　
　　书里也有一些有趣的信息：身为C创始人之一的Ken因为没有通过Google的C语言能力测试而没有提交代码的权限（原因是Ken认为自己根 本没有必要参加这种测试）；Erlang的创始人Joe本身是一个学物理的phd，因为实验室没有经费生活无法维持才跑到Ediburgh的 Machine Intelligence Lab学习CS。
　　
　　-----------------------------------------------------------------
　　
　　PS：原来的标题”去他的算法内功基础，对于程序员，实用主义才是王道“误导性太强，故将其换下，在这里感谢guancheng，AKW等网友的评论。
　　重申一下，我可没说算法基本功不重要，我要表达的意思是：算法并不是编程的前提条件，数学也不会阻碍一个人成为优秀的程序员。

转自：http://blog.csdn.net/peacon/archive/2011/01/15/6143359.aspx
读完图灵俱乐部译的《编程人生》的前两章，给我第一感觉就是：听君一席话，胜读十年书。 Peter Seibel先生对编程先驱Zawinski、Fitzpatrick的访谈非常精彩。从这两章访谈中，我收获到了以下几点：
1. 保持好奇心，充满激情，编程人生才精彩，编程人生才快乐。著名黑客Zawinski好拆卸电子玩具一样对软件的内在充满了好奇，Fitzpatrick从 小就对软件的神奇如痴如醉。同时，Fitzpatrick告诉我们，绝不能把编程仅仅当工作来看待，而应该是一件充满乐趣的事情。换言之，作为一个软件开 发者，如果你仅仅以薪资衡量你的代码的话，那么还是赶快找个后路吧。
2. 语言没有优劣之分，在语言之间的优劣性方面打口水战是毫无意义的。在Perl语言方面，Zawinski和Fitzpatrick就存在巨大的分歧。 Zawinski认为Perl的语法太过古怪，数据结构一团糟；而Fitzpatrick就非常喜欢Perl的灵活性。而在C++语言方面，两位大师表现 出一直性厌恶型。不过，对C++的厌恶只是厌恶，Fitzpatrick还是得用C++来构建高性能的程序。
3. 大师们与我们同在。Zawinski为Emacs贡献了很多。在我们用Emacs编辑代码时，Zawinsk与我们同在。当我们使用memcache这个Web前端利器时，Fitzpatrick就与我们同在。
4. 教育要从娃娃抓起。Zawinski和Fitzpatrick很小就接触了编程，发现并且发展了这方面的能力，终成一代大师。
5. 做软件产品，情况不同，侧重点也不同。做新产品抢地盘，及时推出质量合格的产品才有生存的机会。而有条件的话，早期更充分的考虑软件产品后面运营可能遭遇到的问题，后面改动的成本就会大大降低。
后面还有十三位大师的访谈录，真想知道会带给我些什么更精彩的内容。

转自：豆瓣 作者：厚脸皮
以访谈录的形式来将15位软件先驱的方方面 面融合到一本书，起码对于采访者有非常高的要求，这点来说，Peter Seibel做的非常成功，他对技术及程序员到软件先驱的成长路上的经验与挑战有很好的把握，也就是说，通过Peter的访谈，读者基本能找到自己想要 的，也正是本书的一大特色，不需要软件先驱们自己立传出书，而是通过一些轻松的访谈甚至是类似脱口秀的方式来布道解惑。
　　
　　我一般喜欢在下班之余，一个人在空荡荡的办公室看上一段，看的比较慢，但是收获还是挺多的。同为80后，我很好奇Fitzpatrick（偶 一直怀疑Fitzpatrick是不是Fitz与Patrick的合体*_*）的成长历程，该君生于1980年属于前期的80后，5岁的时候就在父亲的有 意引导下在appleII上进行编程（这是个很好的开端，5岁的时候偶还在和泥巴、玩鼻涕……），6、7岁的时候阅读appleII程序员手册……不过此 君还真的算天赋异禀，最好的表现就是在6岁的时候能抽象出打印变量然后用一行代码代替40行代码（估计就是36个字母加上一些标点）的事例，对比我大学时 候一位师弟不会for循环直接写N次代码的往事，此君简直就是天使。
　　
　　我最喜欢的一个小故事就是Fitzpatrick向同学兜售自己写的游戏，当时显示器支持2种模式，EGA和VGA，需要不同的贴图处理，估 计此君程序检测显示接口不是很健壮，所以经常导致很多同学买了游戏，回去运行就是黑屏，然后家长就电话过来向Fitzpatrick的母亲说 Fitzpatrick拿了个没用的东西在他孩子那骗钱，于是的母亲就开车带着Fitzpatrick去该同学家上门服务，解决软件问题。这情形看起来挺 搞笑的，也很温馨，不说误工费，或许Fitzpatrick妈妈开车来回一趟的汽油费都不止Fitzpatrick卖游戏的钱，可是他妈妈还是如此的支 持。
　　
　　Fitzpatrick君在中学的时候因为痴迷CGI而说服当地ISP运行他自己写的一个投票脚本，也就是后来流行的FreeVote；之 后，进大学的前一年，Fitzpatrick开始了LiveJournal，运营LiveJournal期间，Fitzpatrick在解决 LiveJournal运营问题的时候，发布了memcached和perlbal等优秀的开源软件，具体的原因及解决问题的步骤，这里不再复述：），通 过大学期间运营LiveJournal，Fitzpatrick发现并解决问题，成为他成长的一个黄金时期。在回顾自己大学生活的时 候，Fitzpatrick觉得在大学期间经营事业是最好的方式----对比起那些在大学仅仅完成学业的同学，或者是提前退学经营事 业，Fitzpatrick在学业与事业中找到了一个很好的平衡点。
　　
　　Fitzpatrick因为熟悉Perl等高级语言，但是他还是强调底层的重要性，认为高级语言程序员还是很有必要知道一些底层知识。
　　
　　Fitzpatrick眼中优秀程序员的最大特点就是自我驱动，能做很多没有人安排他做的事，积极主动，对工作充满激情----这个也就是目前Fitzpatrick在Google招人的必要条件。
　　
　　一些来自Fitzpatrick的建议：
　　1.像科学家般的思考，一次改变一样东西；
　　2.有耐心，试着去了解问题的本质，学会增量的开发；
　　3.学习提高沟通技巧，包括在邮件列表里的书面沟通。

转自：豆瓣 作者： Franz
前些天和同事开玩笑的说，你愿意花10元钱去听对一位世界顶级大师的采访么？几乎所有的都表示愿意付更多的钱也去。
　　
　　对呀，很便宜不是么？我读到了这本《编程人生》（英文版名称为Coders at Work）有十五位编程大师的访谈，我在读书的时候大赚了一笔。
　
　　当然我读这本书不是赚了“心里账户”里那一百多元，更让我认识到的他们思想和我的差异是那么的大啊。我近两年才认识到那一切花哨的东西都是浮云，我更注重思想方面的东西，在这之前我特爱追求这样那样的特性，研究各个版本的API差异。
　　
　　这些顶级大师们的想法都各异，我对他们的想法有很多还是不能理解，不过我想先了解了在以后试着去理解。他们毕竟都是从打孔写代码的那个年代过来的人，他们对C++以及OO都有别样的看法，或许他们足够聪明到能在各个思维的层面上自由穿越吧。
　　
　　书中采访方式的确特别像《鲁豫有约》、《艺术人生》，读起来也特别的轻松，因为轻松所以也就使人愉悦。粗略的来说基本上就两步：
　　
　　第一步：忆童年，回忆牛人的计算机发展历程，谈计算机的变化。
　　
　　第二步：谈经验，谈牛人对语言的喜爱、谈工具的使用、谈算法的素养、谈技能、谈面试等等。
　　
　　虽然套路都是这套路，但是每个问题每位大师都给出了不同的答案，人物自传都是描述的人物的发展历程的，人物不一样历程自然不一样。
　　
　　我记得在大学里就开始意识一个问题，我平时动手的时候比动脑的时候还多，先瞎撞一通不灵的时候才真正发挥大脑的作用。我现在想一些比较难的问 题的时候我都离开电脑，思路在离开电脑后就边的好多了。我发现即便是大师们也有类似的习惯！他们的也许是因为有了这样那样的好习惯才能成为大师，我打算把 他们的（我认为的）好习惯去实施一下。

转自：豆瓣 作者：杨爽
很高兴收到 图灵出版社<<编程人生>>这本书，这本书汇集了众多杰出的程序员先驱者们的故事，比如Unix，C语言作者之一Ken Thompson、算法巨著<<计算机程序设计艺术>>的作者Donald Knuth。作为热爱编程的一员，能在这里了解到他们对职业生涯的想法以及对编程的看法实在是太棒了，于是收到这本书时，我很激动且毫不保留的将这书推荐 给我的同事和朋友（本文的另一作者灾难）。
　　
　　这本书通过采访的方式并辑录而成，也许在这种谈话方式下其回答可能会不全面，但这是他们最真实最直接的编程感受和体验。从访谈交流的过程中字 里行间体会到他们对所从事的工作的热情，并享受以此带来的乐趣。工作而非工作，是生活中的巧克力。因提快程序速度而兴奋；因新出语言特性不合理而愤怒。他 们在程序的世界里面享受产品与技术带来的欢乐、抽丝剥茧得到真相的成就，为了计算机领域更加美好的拼搏。
　　
　　Brad Fitzpatrick在他的程序世界搭建自己的世界，在他的程序世界里面有他的生活，程序中有他的生活乐趣，因为父母看到了孩子喝酒的帖子，想起了 “啊，要做个权限了。”；想取笑朋友一篇傻乎乎的文章，“啊，要做个评论的了。”因为觉得有趣而编程，因为编程生活变得有趣。
　　
　　Jamie Zawinski觉得要从产品的角度去生产，而不是为了抽象而抽象，不能因程序员的过度追求完美而过度设计，有些为了完成功能也许采用了不是很完美的解决 方法，可是这样能让产品推出去，而不是成为没人使用过的代码。Douglas Crockford极力反对ECMAScript4纳入ECMAScript语言标准里，努力推进WEB向前发展。作为JavaScript的布道者，从 更高的角度去修正ECMAScript规范，以WEB的发展为己责，优雅的编程，用程序写作，从语言的特性出发去了解语言，利用该语言编写优美的程序，就 像写散文一般，从艺术的角度解读程序；计算机领域有着产品生产以及计算机科学领域，从他们的谈话中，有些如何在产品生产和计算机科学领域中平衡的观点值得 借鉴。
　　
　　Ken Thompson对于代码的编写认为不是一成不变，当发现了新的程序结构划分或更好的实现方式会修改它，当发现旧的代码实现混乱难于修改便扔掉这些腐烂的 代码，对于现有的代码，他的态度是从不迷恋，这也许正应对了我比较认同的一句话“天天重构，每天重构那么点点。”
　　
　　记录这些谈话并不是漫无目的的，从几个方面和这些软件先驱者进行问答，对于编程语言的想法、对于团队管理的想法、对于编程方式的想法、对于程 序产品的想法、对于设计架构的想法、关于编程调试、怎样培养新人的想法。从这本书中得到这些软件先驱者多少年积累下来的经验以及思考，可以从他们的视角去 看待这些问题。虽然有些问题解决场景在今天来说并不适合，可是有了他们在这些问题上的探索，我们在解决同类问题时多了些参考与思路。
　　
　　从他们的经验中得知他们走过怎样的路，什么样的路是失败的路，怎样才是比较好的解决办法，如何去思索现有的问题，如何去解决，当然他们的经验并不对每个人都适用，对于我们这些后来者而言，吸取精华为己所用，体会编程带来的快乐，让我们享受编码的过程吧。

转自：豆瓣 作者： guancheng
我要站出来批评一下那个名为“去他的算法内功基础，对于程序员，实用主义才是王道” 的评论（我的评论对事不对人）。
　　
　　首先我要说，这个观点绝对是错误的。表面上这句话好像抓住了“实用主义”的大旗，但却借此抨击算法等基本功的重要性，太误人子弟。就拿 Google Fellow Jeff Dean来说，他绝对算得上是实用主义的大师了吧？可是如果你去看看他关于Google整个系统架构演变过程的讲座，你就会发现把Google的那些诸如 MapReduce、GFS之类的看家法宝化繁为简之后都可以还原成最基本的算法、数据结构之类的问题！Google整个架构的发展也是根据需求的变化而 产生的，MapReduce之类的不就是在遇到需要解决大规模并行编程这个问题时产生的实用的解决方案吗？没有扎实的基本功它能被设计出来么？哪一个大师 没有扎实的基本功？哪怕是你说的Jamie Zawinski，如果他算法基本功没有十分纯熟他能被称为大师么？别以为他标榜实用他就没有扎实的基本功了。
　　
　　我的观点是，想真正成为杰出的程序员，没有扎实的基本功是绝对不可能的，因为你会发现当你需要解决一个没有现成答案的问题时，你的基本功就是 最可信赖的武器。所以，如果你不想只做一个码农，好好学好算法打好基本功是绝对值得的！当然，如果你只像做一个只能靠google搜索答案过活的程序员， 就当我这话没说。
　　
　　这本书最大的益处就是帮助广大程序员了解大师是怎么成长过来的，学习他们的宝贵经验。我觉得对于程序员来说，大师的成长经历都隐含了一个基本 规律：他们都是编程至少十几二十年以上才最终成为大师的，“十年学会编程”并不是什么天方夜谭，而是确确实实的事情！同理，任何人如果想要成为大师（或者 至少是杰出的程序员），那么他首先要做的就是打好基本功：08年图灵奖得主Barbara Liskov博士在回答“什么素质是研究者必不可少的素质是”她毫不犹豫的说是扎实的基本功最重要。对于学生来说，基本技能和解决问题的能力很重要，非常 重要！这个道理对程序员来说是一样的！
　　
　　成功的方式有很多种，事实上很多商业上的成功案例中技术仅仅是其中最不重要的一环，在中国这个讲究关系的环境中更是如此。我认同市场>管理>技术。我建议大家根据自己的特点来选择合适的职业发展路线。
　　　　
　　随着中国IT行业的发展，科技创新将会变得越来越重要，而超级程序员也会越来越成为香饽饽，如果各位同学确实热爱编程，愿意一辈子编程，我希 望你坚持下去，因为只要你成为超级程序员肯定会有赏识你的公司。现在的盛大创新院好像做的不错，他们给高级研究员年薪能有30W+，可以算是一个招聘高端 人才的例子。而一个反例就是不依靠科技创新的公司（例如团购网站），它们确实是不怎么需要高端人才的，这样的公司不是靠技术取胜。
　　
　　感兴趣的朋友可以看看我这篇文章：Erlang User Conference 2010见闻（兼谈程序员职业生涯） http://www.parallellabs.com/?p=867

电子版啥时候出呢？刚买了《编程大师访谈录》的电子版，好想把这本也买了。

2个购买地址都缺货，现在

现在在当当有纸质书可以买，分为上下两卷，链接如下：
http://product.dangdang.com/23604385.html
http://product.dangdang.com/23604386.html