(先设计算法还是先编写程序)(视觉算法程序编写)

上个月出了几次差，火车和酒店里断续读完了《Unix传奇：历史与回忆》，这书21年拿到读了开头就知道是好书，拖到上个月才找出时间分三次读完。不少技术作品掺水严重，反过来纲举目张读一知十的作品就很少，这些搞出Unix和C语言的大牛，从Brian W. Kernighan到Ken Thompson, Denis Ritchie，一个比一个humble,和humor. 一点儿片儿汤话都不会说，更别说抛大词了 。用谦虚这个词评价总觉得不对。字里行间仿佛都努力把自己放的很平很低，又不是刻意为之。也许当时的技术限制，复杂度和资源，让大家面对问题时候，有平常心吧？- 我常想，他们要是听到咱自称“码农”，大咖大神的称呼他们以及标榜自己，一定笑掉大牙。

记住，写Unix历史和回忆的老头子，当年也是爱搞恶作剧的年轻人，他们是老婆回娘家几天，一口气宅在家里写出Unix操作系统内核，用1小时一口气把酝酿8年的管道Pipe实现的“just for fun”的宅男。这样的书，读起来就想起过去的青涩岁月，读起来很慢呢，一两页就联想颇多搁在一边，想起在Moto也是几年的工作就是在和内存受限的系统斗争，抢每一bit内存空间，还有从汇编逆向工程，像是Unix早期岁月的常态，到了Linux服务器普及的互联网和云计算时代，计算资源反而是粗放经济了。至于他总结的贝尔实验室鼓励写书，"龙书"等经典的由来，今天也没几个公司或工业研究机构能赶上贝尔实验室的认识水平。

还要说一下，《Unix传奇：历史与回忆》的中文版翻译质量很好，韩磊口语话和文学化翻译的努力，是相当值得尊重的二次创作。我这些年陆续翻译了几本书，对翻译也有自己一个循序渐进的认识。一般滴，对于技术技能型书籍，我觉得没必要翻译，读原文最能体会出原意和精髓，大不了用机器翻译也能了解意思。但是一本书要是翻译成书出版，则万万不可用机器翻译+润色的模式 - 那样多好书，因为糟糕的中文，成了买回来读了一次再也不想碰，后悔不如买本原版读的鸡肋。另一方面，译者对语言风格、口语化和再创作的努力，有审美上的效果 — 那些说哎呀看不惯“意译”努力的，是你们自己没有审美的能力和语文太差，不能拉着努力的译者向下兼容 - 要那样，你就配得上机器翻译而已。

审美能力，在任何时候都是一个人最无法作伪的综合素质，是硬伤。被PUA成一个工具人，没有审美和鉴赏能力，还要批评别人，我就不知道该说什么好了。看到那些标榜自己是如假包换的技术直男，不屑于沟通和理解他人，就仿佛看到拍胸脯自豪滴讲“老子是粗人”的文盲，可怜之外无话可说。

出版社峰松兄问“老何可曾为Unix传奇写了一点什么没有？”我说“没有”。他就正告我，“你还是写一点罢；我这里都是豆瓣上的书评，诺诺诺，谁谁谁。。。”，我觉得这本书简明扼要，你想复述或总结任何东西，都不如Kernighan书里写的更恰到好处了，干嘛狗尾续貂呢？要不我就借这本书，回忆一下自己的computer生涯吧，就成了下面的样子：

我接触计算机是1980年代中期，国内一些初中引进计算机作为“科技竞赛”兴趣班，把一些学习好脑瓜子灵的同学组队。我有幸在也是半桶水的指导教师带队下，根据市里面“计算机竞赛”的出题范围，学习Basic语言解决一些诸如“用循环语句用*打出“春节” 两个大字、以及“编写一程序计算出下面几何形状面积”这类竞赛题。记得比赛和培训用的是类似Apple II的组合，键盘和主机一体，连上黑白电视调试。

大学期间，一位硕士师兄从国外回来，带回来一套3寸“BorlandC + + 2.0”安装盘，于是实验室机器上就有了一套极具professional美感的DOS IDE， C + +编译器、TASM、Windows 3.0 开发库和Turbo debugger的环境。单单是这套IDE的美感，引得我快速偏离了航道，找了本Windows3.0下窗体开发手册，在草稿上计算好窗体左上右下的坐标，编程实现不同背景窗口下的参数曲线。我们几个买了一堆质量比较好的三寸磁盘，找隔壁组师兄借来BC++ 安装盘，准备“copy”一套心仪的安装盘 - 总也不成功，后来这位师兄神秘兮兮告诉我们，3寸软盘上特殊的地方”做了坏点”-是没法拷贝的，只好作罢。以前受够了去计算中心排队提交打孔卡Fortran程序的导师，从国外带回的一台286据说用了几万人民币，等到我做课题时候，已经用上了486。不过，硕士导师编写数值算法写的Fortran程序，我们低年级硕士读起来很费力，后来一位博士师兄说，老师有自己的命名习惯，那些i,j,k和ii，jjj, kk 都有特别的规律，代表巴拉巴拉变量和巴拉巴拉层循环。。。后来导师看我们沉迷于计算机本身，偏离了数值计算方向，就给我们讲什么卡尔曼滤波器的神奇之处，讲了些分形和科学可视化程序把我们拉回正道。

再往后读博和工作以后，已经是Windows95/NT编程的天下，那时候搞工控做项目，要买一套MS的MSDN光盘贵的要死，特地从上海跑来北京出差，除了正事儿是买德州仪器买TI DSP芯片，小心翼翼用牛皮纸袋装好 - “就这块尾货了，别让静电毁了” - 我从长安街上巧克力大厦下楼时，TI的人还在后面叮嘱。随后去中关村，从玻璃柜台下面买了两张上个版本的MSDN - 新的太贵了，我还在读博，经济不宽裕，这也能指导咱把上位机程序从Win95向Windows NT环境移植啊。

工作以后转向Unix是在Motorola SSG软件中心，Motorola软件中心2000年通过CMM5，标配是Sun Solaris的PC工作站，Rational Clearcase 做SCM管理，要设计手机基带和多媒体处理的feature在DSP上实现，常常要和美国的团队以及其它模块一起Night build。那个时候大家的工作更接近《Unix传奇》里贝尔实验室的工程师们，也还没有自贬身价不求上进的“码农”这个词 - 大家都是“软件工程师” - 工程师的意思，就是我们做echo&noise control模块的，就要深研声学原理，设计滤波器、舒适噪声算法、然后从HLD到LLD用汇编语言在DSP片子上实现，而隔壁做语音识别的，就要把隐马尔可夫链搞的透透的，这是工程师的态度 - 成为搞定一个方向的专家，而不是欣欣然自称“码农”一副没志气的样子。计算机科学的有趣程度，常常让工程师偏离道路钻进一个个software tools的坑里，特别是Unix独特的产品哲学诞生的一些“拜物教” - 比如典型的Emacs vs. VIM 大战。我的美国Motorola上线，开发环境深度配置为Emacs, 我则是Vim的拥趸，除了算法、debug、工作，一点儿小乐趣就是越来越胖的.vimrc和一堆插件把玩成了IDE，签名档放一个Vim的logo，然后用vim的calendar plugin一直写了7年的日记。。。逢人就宣传Vim PK Emacs.幼稚吗？倒挺怀念那种单纯的乐趣。

离开Motorola后我加入Intel，就开始十多年在Linux风靡server操作系统的HPC技术生涯，直到近5年多的云计算开发模式。肇起于Bell实验室一批年轻的工程师开发的Unix和C语言，是今天互联网时代的真正基底。

这像是一个软件工程师沉迷于 “事物本身的乐趣”陷入了“tools dilemma”的例子，就是陷入对计算机操作系统和工具链本身的痴迷，忘记了要解决的问题才是最重要对象的例子。但这就是《Unix传奇》里面的氛围，简单纯粹。

前两天和一个多年老友吃饭，他问一个问题，我们国内IT企业和科研都这么卷了，为什么从创新到成果都还是不如一些500强老牌呢？ 如果读完《Unix传奇》里Bell实验室的工程师文化，就能给出一个还算像样的回答：长期保持聚焦技术的浓度，摆脱其它一切把大家抽离出这种氛围的东西。不要PUA，不要喊口号，不要搞七搞八，坚持长期主义聚焦产品本身的投入，让大家只对解决问题本身感兴趣，尊重科学发现和技术突破的规律，死磕到底。

冯唐在《万物生长》中有一段儿经典文字，我曾拿来比喻招聘时如何区别“技术导向”与“技术市场导向”人才的方法。这段话是这样的：“抬头望望天上数不清的星星，想想生命从草履虫进化到狗尾巴草再进化到人，再琢磨一下心中患得患失的事情，你也会有一点智慧。争斗的人，追逐的人，输的人，赢的人，都是苦命的人，薄福的人。事物的本身有足够的乐趣，c语言有趣味，《小逻辑》有趣味，领会这些趣味，花自然会开，雨自然会来。” - 这里的关键是 - “事物（技术）本身有足够的乐趣”，矢志于技术道路的人，首先应当能够从中得到足够的乐趣，浸淫其中自得其乐，就像贝尔实验室这些发明锻造出Unix的前辈们，“花会自然开，雨会自然来”。