编程人生

按有用程度 按页码先后 最新笔记

• 

  第111页

  Dexter.Yy (Defensive pessimist)

  JavaScript用户的斯德哥尔摩综合症：微软不想改进，所以这语言也就这样了，用lambda代码来实现所有东西是一个优势，干嘛还要更好的语法 Oh, it only does what it does because Microsoft stopped letting it improve, so why should we want better syntax; it’s actually a virtue to go lambda-code everything. Eich认为现在是程序语言发展的第二个黄金时代，应该重视语言本身的改进，不能止步不前，由于web重视兼容性.. (更多)

  JavaScript用户的斯德哥尔摩综合症：微软不想改进，所以这语言也就这样了，用lambda代码来实现所有东西是一个优势，干嘛还要更好的语法

  Oh, it only does what it does because Microsoft stopped letting it improve, so why should we want better syntax; it’s actually a virtue to go lambda-code everything.

  Eich认为现在是程序语言发展的第二个黄金时代，应该重视语言本身的改进，不能止步不前，由于web重视兼容性，所以JS止步的太久，但不能以此为借口拒绝改进。

  关于为什么要改进

  跟Doug Crockford相反，Eich认为JS不能过于精简化、子集化，不能只保持de-sugar之后的几个原始特性（比如lambda），因为:

  It’s very reductionistic and it’s not for everybody.

  Subsetting is powerful. But to say everyone has to program in this sort of minuscule subset, that’s not usable.

  tries to make everybody into an expert and it will not work on the large number of programmers out there who have been mistrained in these Java schools.

  当初不把JS设计成一个纯粹的lambda x86语言的理由也是一样：不是每个人都想成为superhacker，程序员中也有一个金字塔。

  lambda是JS的理论优势，但Eich认为要让JS兼具理论和实用的优势，就不能仅仅为了纯洁性而放弃好用的功能。

  Doug等人传播了一些模式去解决JS的问题，某种程度上来说很成功，让普通开发者们在patterny level上了解到很多函数式编程的概念和惯用法，但Eich更同意Peter Norvig的观点：模式反映出程序语言本身存在某种缺陷。这些模式不是免费的午餐。

  另一个改进的理由是，尽管程序员们可以通过写抽象库，自己解决很多问题（而且Eich非常欣赏一些JS库，认为它们令人振奋，反映了人们是何等聪明，能用非常小的工具集做出非常合理非常方便的抽象），但这种抽象能力在现有的语言中还是受到了很大限制，所以语言本身需要扩展。

  关于如何作改进

  除了Eich的blog连发的三篇文章里提到过的重大改进（比如proxy和for-in语法），这篇采访里还反映出他本来早就想引入macro，因为担心这个过程耗时很长研究性质很强，没办法吸引到微软，所以暂时搁置了，但他们一直在确保现有的和即将加入的语法糖能随时转化成宏:

  we do make sure we can recast all of the sugar as macros when we have macros.

  当Seibel询问对Knuth的文学化编程（literate programming）的看法时，Eich提到他对于doc comments和doc strings的兴趣，认为缺乏自动从注释里提取信息转化成可读文字和自动检查的手段，literate programming包含了整合测试和注释的含义。他们曾在ES4里做过尝试（AS3的metadata算么）：

  We tried to add doc comments of some sort to ES4 with first-class metadata hooks or reflection hooks and it was just impossible to get everybody to agree.

  此外Eich对静态语法分析有极大的兴趣（他的blog里也有相关的文章），他提到这是他们希望JS具备可选类型的原因之一：

  That was one of the reasons why in JavaScript we were interested in optional typing and we still are, though it’s controversial in the committee. There’s still a strong chance we’ll get some kind of hybrid type system into a future version of JavaScript.

  嗯嗯其实我想说的是……以上三点（宏、文档注释、静态分析）正好都包含在我去年开发的JS预处理器的愿景之中呀~木哈哈哈哈，所见略同所见略同~

  好罢这其实是111页的前后几页的笔记……不过都是同一个话题……

  P.S. 学到一个新的骂人话：Java是一种“blue-collar language”（中文版翻译成“IT民工语言”）

  再P.S. 全篇都充斥着Eich和Doug的基情口牙~~提到Doug的次数太多了~比如：

  Seibel: Was the ES4 proposal your chance to show the world that, “Look, I’m a really smart guy and JavaScript is a really a good language”? Eich: No, I don’t think so. I know Doug may think that. I don’t think Doug knows me that well, but the thing is, I’m not really looking for respect, especially from the Java-heads or the trailing edge.

  (收起)

  2011-03-26 19:56:39   1回应

  收藏

  推荐
• 

  第388页

  kongxx

  Seibel: 不精通技术却擅长团队协调的人，能成为好的管理者吗？ Allen: 这不是不可能，不过他得首先承认自己并不精通技术，其次还要能分辨团队中谁擅长技术，谁不擅长技术。 回答的太对了，简直是一针见血，公司有些人是得好好理解一下。 (更多)

  Seibel: 不精通技术却擅长团队协调的人，能成为好的管理者吗？ Allen: 这不是不可能，不过他得首先承认自己并不精通技术，其次还要能分辨团队中谁擅长技术，谁不擅长技术。

  回答的太对了，简直是一针见血，公司有些人是得好好理解一下。 (收起)

  2011-06-06 20:51:58   回应

  收藏

  推荐
• 

  第149页

  miao

  我认为C++早已经超越了它的复杂度极限，但是还有很多人用它编程。可这实际上是逼人们只使用其中一个子集有很多功能你完全不用，因为使用它们会造成代码太复杂。 这段话是Joshua Bloch说的，说得很直接。某种意义上也说明了为什么C++的code style guide要比python的长那么多。 (更多)

  我认为C++早已经超越了它的复杂度极限，但是还有很多人用它编程。可这实际上是逼人们只使用其中一个子集

  有很多功能你完全不用，因为使用它们会造成代码太复杂。

  这段话是Joshua Bloch说的，说得很直接。某种意义上也说明了为什么C++的code style guide要比python的长那么多。

  (收起)

  2011-03-14 20:24:06   7回应

  收藏

  推荐

• 

  第1页

  kongxx

  现在人写书真是抄来抄去，第一个对Jamie Zawinski的访谈就在去年程序员的合订本的第296页里有，真是无语了，书还卖这么贵，真不值。 (更多)

  现在人写书真是抄来抄去，第一个对Jamie Zawinski的访谈就在去年程序员的合订本的第296页里有，真是无语了，书还卖这么贵，真不值。 (收起)

  2011-04-27 21:30:44   回应

  收藏

  推荐
• 

  第1页

  懒猫

  阅读第一个访谈让人有种蓦然回首的感觉，他对年轻时候的选择隐约中带着一种无奈的不易察觉的悔意，有着些许的沧桑与无奈。当年一个年轻气盛有着自负与骄傲的年轻人在当他已经不再年轻的时候，就像是一只被驯服了的猛兽，多少也让人感到伤感。 跟随着计算机科学一起成长起来的那一代人是幸福的。 当计算机科学还没有那么臃肿庞大，他们做着他们喜欢做的事情，然后不经意间地创造着历史。 访谈中谈到了Richard Stallman,谈到了Ema... (更多)

  阅读第一个访谈让人有种蓦然回首的感觉，他对年轻时候的选择隐约中带着一种无奈的不易察觉的悔意，有着些许的沧桑与无奈。当年一个年轻气盛有着自负与骄傲的年轻人在当他已经不再年轻的时候，就像是一只被驯服了的猛兽，多少也让人感到伤感。

  跟随着计算机科学一起成长起来的那一代人是幸福的。

  当计算机科学还没有那么臃肿庞大，他们做着他们喜欢做的事情，然后不经意间地创造着历史。

  访谈中谈到了Richard Stallman,谈到了Emacs，谈到了netscape的开发过程，谈到了修改编译器，谈到了Stamllman的傲慢，读来也有种回顾历史的意味。 (收起)

  2011-04-29 11:05:38   回应

  收藏

  推荐
• 

  第1页

  edwin.z.w (吉他 摄影 程序)

  k816.16 (更多)

  k816.16 (收起)

  2011-05-28 14:45:41   回应

  收藏

  推荐

• 

  第13页

  Jeffery (正在看书)

  现实世界中，有谁能这么快就发布一款规模不小、质量不赖的软件，同时还能吃住在家，天天睡到自然醒？有过这种事吗？也许有吧，反正我没听说过。 (更多)

  现实世界中，有谁能这么快就发布一款规模不小、质量不赖的软件，同时还能吃住在家，天天睡到自然醒？有过这种事吗？也许有吧，反正我没听说过。

  (收起)

  2012-02-20 10:07:18   回应

  收藏

  推荐
• 

  全文

  comain

  09年一个老外同事那里知道这本书，最近终于把它看了一遍。采访了很多role model, 他们成功的路线各不相同，对自己所从事工作的定为也格式各样(科学家，艺术家，工程师...)。共同点是，大家都认为程序的可读性非常重要。所以，在提交代码之前，多自己看一遍它们吧。 (更多)

  09年一个老外同事那里知道这本书，最近终于把它看了一遍。采访了很多role model, 他们成功的路线各不相同，对自己所从事工作的定为也格式各样(科学家，艺术家，工程师...)。共同点是，大家都认为程序的可读性非常重要。所以，在提交代码之前，多自己看一遍它们吧。 (收起)

  2011-11-20 11:25:05   回应

  收藏

  推荐
• 

  梅尔的故事(p286)

  黄小毛 (more is different)

  　　Mel的故事，一个真正的程序员 　　作者：Ed Nather 　　翻译：CY 　　近来有一篇充分展现男子汉气概的关于编程的文章，其中做了一个大胆而直率的断言：“真正的程序员用Fortran编程”。在当前这个充满清爽型啤酒、掌上计算器以及“用户友好”软件的堕落的时代，也许他们确实是这样的，但如果回到过去的好时光，当“软件”这个术语听起来还显得挺滑稽的时候，那时真正的计算机还是用磁鼓和真空电子管制造的，真正的... (更多)

  　　Mel的故事，一个真正的程序员

  　　

  　　作者：Ed Nather

  　　

  　　翻译：CY

  　　

  　　近来有一篇充分展现男子汉气概的关于编程的文章，其中做了一个大胆而直率的断言：“真正的程序员用Fortran编程”。在当前这个充满清爽型啤酒、掌上计算器以及“用户友好”软件的堕落的时代，也许他们确实是这样的，但如果回到过去的好时光，当“软件”这个术语听起来还显得挺滑稽的时候，那时真正的计算机还是用磁鼓和真空电子管制造的，真正的程序员使用机器码编程——不是Fortran，不是RATFOR（Rational Fortran），甚至不是汇编语言——而是直接使用机器码，原始的，朴素的，难以理解的十六进制数。

  　　

  　　为避免新一代的程序员在成长的过程中对辉煌的过去一无所知，我深感有责任讲一讲真正的程序员是如何写代码的故事（我将尽力避免代沟的影响），我叫他Mel，因为那是他的名字。

  　　

  　　我第一次遇到Mel是在我到Royal McBee计算机公司工作时[1]，那是一家打字机公司的子公司（现在已经停业了）。公司主要生产一种小型的廉价的（以当时的标准）使用磁鼓内存的计算机LGP-30，当时刚开始生产RPC-4000，一种更先进，更大，更好，更快的磁鼓内存计算机。由于核心部件的造价太高，该型号的计算机最终没有完成（这就是你没有听说过这种计算机以及这家公司的原因）

  　　

  　　我受雇于这家公司为新机器写Fortran语言的编译器，Mel是我的辅导员，但他并不认同编译器。

  　　　　

  　　“如果一个程序无法重写它自身的代码”，他说，“那么这个程序有什么用呢？”

  　　　

  　　Mel用十六进制机器码写了那家公司最受欢迎的程序，它在LGP-30上运行，可以在计算机展览上与潜在的顾客玩blackjack[2]，这个程序的效果总是非常引人注目的。每次计算机展览会上当LGP-30的摊位立起来后，IBM的销售人员就会聚在周围互相窃窃私语。至于这种演示是否促进了计算机的销售倒是我们从未讨论过的问题。

  　　　

  　　当时Mel的工作是为RPC-4000重写blackjack这个程序（移植？那是什么意思？）新计算机使用1+1的寻址机制，每条机器指令（machine instruction）中不仅包括操作码

  （operation code）和操作数（operand）的地址，还有一个二级地址，标明了位于旋转的磁鼓[3]上下一条机器指令的地址。用现在的说法，可以认为每条指令都附带着一条GO TO语句！

  　　

  　　

  　　Mel非常喜欢RPC-4000，因为他可以对代码进行优化：也就是说，在磁鼓上设定机器指令的位置，使得当一条指令完成时下一条指令恰好到达[4]“（磁鼓）读写头”的区域以便立即执行。有一个程序可以完成此项工作，即所谓的“优化汇编器”，但Mel拒绝使用它。

  　　　　

  　　“你永远不知道它要把东西放到哪里去”，他解释说，“所以你必须得使用单独的常

  量”

  　　

  　　直到很久之后我才理解Mel这句话的意思。因为Mel知道每一条操作码的具体数值，并按照他自己的方式安排磁鼓地址的分配，所以他所写的每条指令都可以看作是一个数字常量。他可以取出一条先前的加法指令，加上相应的地址偏移量，判断出它的数值是否正确。对别的人来说他的代码很难修改。

  　　

  　　我比较过经Mel“手工优化”的程序以及被“优化汇编器”处理过的相同代码，Mel的程

  序总是运行得更快。这是因为当时“由顶至下”的程序设计方法还没有被提出，当然Mel也

  不会去使用这种方法。他首先写出自己的程序循环中最核心的部分，以保证这些循环可以首先选择磁鼓上最优的地址[5]。优化汇编器还没有聪明到这个程度。

  　　　

  　　Mel从来不写会造成时间滞后的循环，即使慢吞吞的多功能穿孔机在输出字符时确实需要一定的延迟以便正常工作。这种情况下，他会在磁鼓上设定指令的位置，使得每条后续指令在需要时恰好“经过[6]”磁鼓的读写头；这样磁鼓就需要重新转一整圈才能找到这条指令。他为这个过程生造了一个不易忘记的术语。尽管“最优（optimum）”是一个绝对的术语，类似于“唯一”，但在口头上经常会把它相对化，如“不是非常最优（not quite

  optimum）”或“较少最优（less optimum）”或“不是很最优（not very optimum）”。

  Mel把这种造成最大时间滞后的指令定位称作“most pessimum”

  　　

  　　当Mel完成blackjack这个程序并使它运行起来之后（他骄傲地宣称，“即使初始化过程也被最优化了”），他收到了来自销售部门的变更请求。这个程序使用了非常精妙的（优化过的）随机数发生器用来随机选牌并发牌，一些销售人员觉得这个程序太公正了，因为有时顾客会输掉牌局。他们要求Mel修改这个程序，通过控制台上的一个感应开关，可以对程序进行修改并使顾客赢得牌局。

  　

  　　Mel犹豫了，他觉得这是公然的欺诈行为（这确实是的），而且这种行为破坏了他作为程序员的个人诚实原则（这也是事实），所以他拒绝对程序进行修改。于是销售部门的头儿开始找Mel谈话；然后是公司的大老板；然后是一些资深的程序员（在大老板的催促下）。Mel终于还是妥协了，他修改了代码，但当他测试时发现如果开启了感应开关，程序就会作弊，每次都是程序获胜。对于这个结果Mel非常高兴，他声称他的潜意识有着无法控制的道德准则，并坚决不修正这个问题。

  　　

  　　在Mel离开了这家公司后，大老板要求我去研究一下代码并看是否能反转这个作弊开关的效果。虽然有些不情愿，我还是同意去看看。要跟踪Mel的代码确实是一项冒险。

  　　

  　　我经常觉得编程是一种艺术形式，它的真正价值只能被另一个深谙此道的行家所欣赏；代码中隐藏着美丽的珍宝和闪亮的技巧，而这些东西往往隐藏在人们的视野和赞美之外，有时也许是永远无法为人们所知的，而这正是编程过程的本性。你可以仅仅通过读另一个人的代码而学到很多东西，即使是十六进制的形式。我认为Mel是一个未获赞颂的天才。

  　　

  　　最使我震惊的莫过于我发现代码中有一个没有测试条件的正常循环。没有测试条件（完全没有！），常识认为这将是一个闭合循环，程序会进入无休止的循环状态。但事实上整个程序运行一切正常，程序的控制权被正确传入又安全返回。我花了两个星期的时间才弄明白这其中的原理。

  　　

  　　RPC-4000计算机有一项非常先进的功能，被称为索引寄存器。它允许程序员在循环内部使用一条具有索引号的指令来实现程序循环；每次执行这条指令时，索引寄存器内的数字被加上这条特定索引指令的地址，这样每次循环时程序员只需要递增索引寄存器中（原有）的数值，就能依次指向下一块数据。Mel从来没使用过索引寄存器。

  　　

  　　相应的，Mel会从机器寄存器中直接取出机器指令，对其地址[7]加1，并存回去。接着他会从寄存器中执行已经被修改过的机器指令。循环的实现中已经把这些额外的执行时间计算在内了——每次一条指令结束时，下一条指令正好位于磁鼓的读写头之下[8]，准备运行。但循环中的确没有测试条件。

  　　

  　　当我注意到索引寄存器位[9]时终于找到了最重要的线索，那个bit处于机器指令的操作码和地址[10]之间，被置为1的状态——虽然Mel从不使用索引寄存器，该寄存器在运行过程中始终为零。当那道灵感之光亮起来时它几乎使我失明。

  　

  　　Mel把他使用的数据[11]放在内存的头部——指令所能寻址的最大地址范围——所以，当最后一块数据被处理完成后，再增加机器指令中的地址[12]部分会使得它溢出。进位[13]将给操作码加1，并使得它变为指令集中的下一条：一个跳转指令。然后下一步程序指令就会从零地址重新开始运行，所以这个程序将周而复始地继续运行下去。

  　　

  　　我并没有和Mel保持联系，所以我不知道在那席卷所有传统编程技术的改变浪潮中他是否放弃（编程），我更愿意相信他没有。无论如何，在被Mel的代码深深地触动后我选择了退出那项不愉快的测试工作，告诉大老板我找不到修改的方法。他似乎也不怎么惊讶。

  　　当我离开公司时，那个blackjack程序还是老样子，当开启感应开关时程序仍然会继续作弊，我觉得它就应该是那个样子。修改真正的程序员的代码让我觉得不舒服。

  　　

  　　[Posted to USENET by its author, Ed Nather <utastro!nather>, on 1983-05-

  21].

  　　

  　　

  　　附录：

  　　

  　　Story of Mel是程序员中非常出名的传奇故事，尤其是在hacker（不是cracker）的圈

  子中被广为称道，究其原因，不外乎两点：一是Mel对编程本身技术上追求，对代码“优

  化”的精益求精，虽然现代hacker们编程的环境和技术手段已经天翻地覆，但那种对技术本身的执着却是一脉相承的；二是故事中提到的Mel的个人原则与操守，对公司管理层的拒绝妥协和现代hacker们对社会主流文化的叛逆也颇有共通之处。

  　　

  　　Story of Mel于1983年5月21日由作者Ed Nather贴在USENET上，虽然广为流传，但很多人都对故事的真实性均持怀疑态度（故事确实颇有些传奇色彩），但近些年越来越多的证据显示Mel确有其人，他的全名是Mel Kaye，而且故事中提到的利用地址溢出实现的循环算法也同样是有据可查。

  　　

  　　如果在Google上搜索“story of Mel”会有非常多的结果，文章内容虽然大同小异，但

  形式却很多变，甚至有人把原文重新排版，排成了类似散文诗的格式（被原作者称为是对这个故事本身的hack过程）

  　　

  　　如果有兴趣可以查看下列网址获得更多相关信息。

  　

  　　关于Mel确实存在的一些证据的Entry，相关链接包括Mel亲笔签名的源代码清单等等

  　　

  　　http://www.wps.com/projects/LGP-21/mel-the-programmer.html

  　　

  　　LGP-30的用户手册，明确提到Mel Kaye的名字

  　　

  　　http://www.foldoc.org/pub/MelKaye.txt

  　　

  　　Story of Mel的一种散文诗化版本

  　　

  　　http://www.jargon.net/jargonfile/t/TheStoryofMel.html

  　　

  　　

  　　

  　　

  　　

  　　译注：

  　　

  　　[1] 根据相关资料可以估计当时是上世纪50年代末或60年代初

  　　

  　　[2] 也就是通常我们说的二十一点，记得以前我们学校的分时系统上也有个叫

  blackjack的游戏，机器是庄家，用户是玩家，程序会给玩家一定的本钱，如果输光了就

  game over。也许因为机器没有我贪婪，所以我从来都没有赢过它

  　　

  　　[3] 电子管时代，通常把磁鼓作为机器的内存使用；到晶体管时代，很多机器一度把磁鼓作为外存，不过很快被磁盘取代

  　　

  　　[4] 到达，原文是arriving，注意和[6]的区别

  　　

  　　[5] 所谓最优的地址，就是如前面所说的，上一条指令结束后磁鼓读写头的位置恰好执行下一条指令，消除了等待磁鼓旋转到合适位置的时间滞后，核心的程序循环可以优先选择磁鼓上的地址进行优化

  　　

  　　[6] 经过，原文是past，和[4]恰好相反

  　　

  　　[7] 此处的地址是指前面提到的机器指令中的操作数的地址，不是下一条指令的二级地址

  　　

  　　[8] 之下，原文是under，与[4]类似，更加准确地标明指令的位置

  　　

  　　[9] 索引寄存器位，index register bit

  　　

  　　[10] 同[7]

  　　

  　　[11] 数据，即循环部分机器指令的操作数

  　　

  　　[12] 同[7]

  　　

  　　[13] 虽然不用索引寄存器但仍把索引寄存器位设置为1就是为了这个进位（carry），

  因为该位处于操作码和操作数地址之间，如果该位为0，则地址部分溢出后只会把该位设置1而不会造成操作码字段的加1运算 (收起)

  2011-11-07 09:38:22   回应

  收藏

  推荐