谁有这三本书任意一本的中文书评？

Posted 2023-05-16

《世界是平的》 (美)托马斯•弗里德曼
《理解媒介》 （加）麦克卢汉
《信息就是信息》 （美）布隆博格
任意一本，3000字以上。侧重评论。

书评：世界永远不会完全平

——评《世界是平的》

在如雷贯耳一年后，《世界是平的》（The World Is Flat）终于进入我的眼帘。不是我清高，而是我不愿支付从美国亚马逊网店到中国的邮寄费。这次因为要采访作者弗里德曼，我从印度同事Ravi那儿借来了大作，花了两天时间拜读完毕。

第一印象：这人真罗嗦，基本跟我奶奶差不多，一句话（如level the playing field）可以在两三页里重复十来遍。我怀疑弗里德曼是用口述方法写作的，因为行文太像是课堂讲座的笔录，句式繁复，但并不叠床架屋，而是相当流畅，没有哪句话或哪个字需要看两遍才明白。这大概也是畅销书之所以畅销的秘密吧，即千万别居高临下摆出一副大学者的架势，别卖弄辞藻。

若论全球影响，托马斯·弗里德曼可要比大学者大多了。该书长时间雄踞《纽约时报》图书排行榜的首位，但你却不能说那是走后门的结果，因为该报其他专栏作家的书籍远不如他的好卖，可见他说的话真是眼下人们想听的。

对我来说，该书的前三分之二基本上属于老生常谈，如果你平时阅读主流媒体，里面的例子许多都上过封面故事。至于理论，也没有超出微观经济学+对外贸易基础课的范畴。简而言之，科技的迅速发展和经济全球化，消除了经济活动中的种种壁垒，使得世界趋于“平坦”。弗里德曼列举了十大动力，多数都是互联网时代的高科技产品或现象。比如，他把1995年8月9日Netscape的上市当作仅次于柏林墙倒塌的第二大动力。我不敢苟同。1990年我用苹果的Macintosh上网时，虽然介面和速度实在不敢恭维，但未来世界的宏伟蓝图已初露端倪。如果让我选十大的话，苹果1984年推出Macintosh绝对可以榜上有名，尤其是苹果那个“1984”的电视广告，将科技发展和意识形态巧妙地融为一体，比弗里德曼描述十大动力的任何一个事例都更精辟地浓缩了世界的变化与抵制变化的抗争。当然，选十大动力跟选十大电影似的，每人都有不同的排行榜，只要八九不离十，就不算离谱。

你若觉得杨振宁为中国教育大唱赞歌是老糊涂了，那么，本书中弗里德曼的誉美之词足以证明杨振宁不是在拍中国教育部的马屁。书中关于中国大学生百分之六十学工程的数据，我也深表怀疑。在我看来，中国和美国的教育刚好走了两个极端，因此，站在各自的立场，肯定只看到对方的长处，看不到对方的短处。如果删除书中涉及意识形态的词句（据说国内书商的确这么做了），该书对于中国的评价之高，放在央视《新闻联播》中朗读都没问题。比如作者转引著名风险投资家约翰·多尔对中国领导人的评价：“你跟中国的领导人谈话，他们都是工程师出身，他们能马上明白事情的症结在哪里。美国领导人则做不到，因为他们都是律师出身。”（As venture capitalist John Doerr once remarked to me, “You talk to the leadership in China, and they are all the engineers, and they get what is going on immediately. The Americans don’t, because they’re all lawyers.” P280 本文中翻译有些是大意，故附原文和页码。）

另一句咱们领导人会觉得很中听的，是引述《共产党宣言》中的一大段，是一位哈佛政治理论教授告诉弗里德曼的。书中引用了大约一页。令人惊讶的是，马克思和恩格斯在这一页的篇幅中，把弗里德曼花了两三百页才讲完的内容概括了起来，而且说得极为精彩。这篇1848年出版的文章，只要把“资产阶级”改成“企业家”，完全适用于当今世界。真是神人！还有一点让我感叹的是，老马的文字原来那么生动，那么富有文采，我以前从来没读过他的英文版，而小时候攻读中文版，基本上跟蜡烛味道差不多。

当然，弗里德曼并不会同意老马的结论（本书并未引述）。在谈论美国面临的挑战时，他写道：“冷战期间美国的主要挑战是实行极端共产主义的国家，如俄国、中国、北朝鲜；现在美国面临的挑战来自实行极端资本主义的国家，如中国、印度、南朝鲜。”（The main challenge in that world was from those practicing extreme communism, namely, Russia, China, and North Korea. The main challenge to America today is from those practicing extreme capitalism, namely, China, India, and South Korea. P277）（“删除！删除！”我彷佛听到出版社编辑的大声叫喊。）

书评：《世界是平的》
林嘉澍=文 2006年3月26日

《世界是平的(The World is Flat)》一书之中，弗里德曼将全球化分割成三个阶段。“全球化1.0”主要是国家间融合，始于1492年哥伦布打开新旧世界的贸易大门，直至公元 1800年前后，劳动力推动着这一阶段的全球化进程；“全球化2.0”是公司之间的融合，从公元1800年持续到2000年，其间被大萧条和两次世界大战打断，硬件的革新扮演着主要的推动力——从蒸汽船、铁路再到电话和计算机的普及；而在“全球化3.0”中，个人成为主角，肤色或东西方文化差异不再是合作或竞争的门槛，软件的不断创新让大洋两岸的人们可以通过海底光缆轻松实现自己的社会分工。

历史似乎正进行着一次有趣的轮回。五百多年前，哥伦布使用简陋至极的导航技术穿越海平面，并安全返航，以此证明“世界是圆的”。他们在茫茫大海中折腾了71个昼夜，一直到1492年10月3日凌晨，才发现第一块陆地。哥伦布深信他脚下所踩的正是印度，而实际上，那是后来被命名为“亚美利加(America)”的崭新大陆。几个世纪后，美国最受欢迎的专栏作家光顾真正的印度。他发现，这里的人们在顶尖学府里接受教育之后，已经掌握了当今最先进的科学技术。世界仿佛骤然变平——正像那些印度工程师面前光滑如砥的液晶屏幕，鼠标点击之间，已经能够轻易调动遍布世界的产业链条。

弗里德曼同样进行了一次目的地为“印度”的旅行，但却对世界得出了与哥伦布截然相反的结论。他将自己比作现代版的哥伦布，却在有意无意之间犯下了一些与前辈异曲同工的失误——沉溺在自认为精彩的结论中以至于难以自拔。在将近 500页的著作中，他为了支撑自己的观点而不断地书就一些意义不大的文字：“我的上帝！”“哇噢！”“孩子！”“当世界变平的时候，你会感到自己也被铲平了！”

弗里德曼竭尽全力地证明“世界是平的”。他和许多人交谈，大段大段地引用其他作者的文章、E-mail、官方报告、广告片花、演讲稿和调查数据。他的书里包含了大量的信息，而且像染有怪癖的记者一样地不停抛出各种名字。显然，弗里德曼的问题并不在于细节的贫乏，而在于整本书读起来乏善可陈。他一遍又一遍地重复几近雷同的阐述：“世界越来越小，变革正在无情地推进，许多事情开始变得不一样，但我们不要为此感到恐慌”。抛开纷繁复杂却换汤不换药的故事，《世界是平的》几乎只给出了这些观点。而更要命的是，这些故事在《商业周刊(BusinessWeek)》和《经济学人(The Economist)》之类的杂志里几乎随处可见，只要读者不是在密室里被关了五年禁闭，那关于外包工业的新闻几乎早就可以倒背如流。

作为三次获得普利策奖的新闻工作者，托马斯•弗里德曼最著名的写作路数，就是在永不停歇的旅行中与有趣的人们会面，并把聊天过程拿出来与读者分享。弗里德曼和这些人谈话的标准方式是，先把他的戴尔笔记本重重放在桌上，然后在采访过程中一路快速地输入。但在批评家们看来，弗里德曼只是在不停讲述一些发生在小圈子里的事情。英国《卫报(Guardian)》毫不留情地对此揶揄道：“他笔记本上的‘I’键可能需要翻修了。”弗里德曼在书中说了太多的“我”。读者可以了解到他的家人、朋友和饮食习惯，甚至是对他新闻学老师的赞美之辞——“我直挺挺地坐着，脑袋里只有她！”

全文见： http://www.flypig.org/001772.html 参考技术A 清醒的乐观与本位的忧患——《世界是平的》透视
http://www.cbr.org.cn/data/articles/b06/1295.html
这本不是得了普利策奖嘛，也许那儿有评价。
我正在看，觉得角度新，题目好，就是通篇太强调
“世界是平的”了让人忍不住有点反感，不管什么事，情况是很复杂的吧。本回答被提问者采纳

《Elixir in Action》书评及作者问答录（作者 Sergio De Simone ，译者 邵思华 发布于 9月29日）

《Elixir in Action》是由Manning所出版的一本新书，本书为读者介绍了Elixir这门语言以及Erlang虚拟机，同时也讨论了与并发编程、容错以及与高可用性相关的话题。InfoQ有幸与本书的作者Sa?a Juri?进行了一次访谈。

《Elixir in Action》的内容源自于Juri?在Erlang方面的经验，他为此特意创建了一个博客，为来自面向对象背景的程序员展现Erlang的优势。Juri?之后转而使用Elixir，这是一种函数式的并发编程语言，它的目标是提供一种比起以Prolog为启发创建的Erlang更简便的语法，以及更高等的抽象能力。

本书的内容采取了一种渐进式的方式，首先介绍了Elixir的语法与它的基本特性，例如宏、模式匹配、模块、多态等等，随后介绍了如何创建一个容错的、高可用的、并发的分布式系统。在全书的一些核心章节中涵盖了Erlang平台的大量知识，其中的主题包括管理进程、持久化、通过supervision树进行运行时错误处理的多种方式，以及“任其崩溃”（let it crash）等设计哲学。

 

总的来说，《Elixir in Action》一书不仅为如何使用Elixir语言与Erlang VM，同时也为读者如何迈进高可用性系统这一领域打下了坚实的基础。InfoQ与Sa?a Juri?进行了一次访谈，以了解这本书背后的更多知识。

InfoQ：是什么原因促使你编写了本书，它与现有的一些针对Elixir的书籍又有何不同之处呢？

Sa?a：《Elixir in Action》的目标是帮助那些具有编程经验，但缺乏Erlang、Elixir或函数式编程背景知识的程序员开发能够在生产环境中运行的系统。在这本书的构思阶段，我就假设本书的大部分读者都来自于面向对象语言的背景。对于这些读者来说，书中的许多内容都是新颖的：新的语言、运行时与生态系统，包括函数式编程与类似于Actor的并发编程思想。读者需要打下大量的知识基础，而这可能会令人望而生畏惧。

我相信，通过一种更为专注的方式，初学者的学习过程将能够得到极大的简化。因此，我并不打算编写一本完整的参考书，而是决定专注于那些对于多数目标读者来说有些不寻常的核心概念：函数式编程、并发，以及OTP框架的核心思想。我相信一旦读者开始对这些主题感觉到“心意相通”，他们在学习本书并未叙述的一些内容时就会更容易。举例来说，如果读者掌握了Erlang中的并发知识，并且理解了大多数最重要的OTP概念（GenServer、Supervisor、Application），那么他们就能够较容易地自行学习其它的抽象概念，例如Task、Agent或GenEvent。

我相信，这是目前唯一一本以这种方式进行撰写的Elixir书籍。任何一位想要使用Elixir/Erlang技术打造可伸缩的、高容错性的分布式系统，都必须学习Elixir in Action一书中所介绍的各种材料。当然，你也可以通过其它资源学习这些内容，但我认为，本书是目前唯一一本面向Elixir介绍以上所有主题的书籍。

InfoQ：你能否简单地介绍一下你在Elixir方面的经验？它对于你实现工作目标提供了哪些程度的帮助？

Sa?a：对我来说，Elixir最重要的一方面实际上是Erlang VM，这是一切功能的基础，这也是我首次接触Erlang时对于我帮助最大的内容。大约5年以前，我当时需要实现一个基于长轮询的服务器推，它需要不断地将频繁变化的数据传输给数以千计的连接用户。经过一段时间的评估之后，我们最终选择了Erlang，我从中也收获了许多经验。Erlang以一种结构化的方式帮助我克服了重重阻碍：使用它创建解决方案的过程非常顺利，即使我对它的开发平台还有些陌生。最终设计出的系统具备了高伸缩性、高效性以及灵活性。我能强烈地感觉到Erlang在支持着我，即使我犯下了各种错误。这套系统能够处理各种预料之外的状况，而我甚至还没有在这方面做过什么计划。

InfoQ：Elixir特别适合于哪些类型的项目？

Sa?a：在我看来，Elixir/Erlang适合于任何类型的服务端系统：即需要持续运行，并且尽可能持续提供服务的软件。这方面一个很明显的示例就是基于web的系统，用于处理传入的HTTP请求，但也需要进行其它活动，例如后台的、周期性的作业或缓存管理。在这种系统中，许多活动在某个具体时间往往处于挂起状态。而Erlang应对这种并发情况的途径让开发者的担子轻了许多。如果每个独立的活动都能够分配至少一个独立的Erlang进程（不要与OS的进程混淆了），我们就不仅能够实现可伸缩性，还能够改善容错性：一个单一的进程故障不会对整个系统的绝大部分产生影响。并且还有许多方法能够检测到这种故障，然后从故障中恢复。

我发现这种处理方式非常直观，并且任意一种类型的后端系统都能够从中受益。我看到某些观点说Erlang只适合于大规模系统，或某些特定的领域，例如电信领域。我不同意这种观点。Erlang能够帮助系统实现大规模化，而这种特质在任何类型的生产系统中都是必要的，无论其规模与领域如何。因为如果某个系统做不到高可用 ，那么它就会频繁地产生故障。即使你不需要实现传说中的9个9的可用性，但你也应当希望让你的系统停机时间尽量减短吧。实现这一点是一个艰难的挑战，而Erlang则能够帮助你实现这个目标。

InfoQ：你怎样描述Elixir与Erlang两者之间的关系呢？

Sa?a：我的看法是，Elixir是在Erlang与OTP所提供的强大基础之上所扩展的能力，旨在提升开发者的生产力。我曾经进行过大量的全职Erlang开发工作，虽然我十分热爱这门语言，但有许多任务也显得过于繁琐，我不得不无谓地处理一些低层次的机械性工作。而Elixir在这方面提供了大量实用的特性，包括语言（例如通过宏进行元编程，以及通过协议实现多态）与工具（例如构建项目的多种工具搭配，以及十六进制包管理器）两方面，这让我们能够专注于处理一些更为实际的问题。

我个人的感受是使用Elixir进行开发比起使用纯粹的Erlang进行开发要简单许多。Elixir使可伸缩性与开发者的生产力之间这种刻意的权衡大大降低了，甚至是完全消除了。仅仅因为某个开发平台允许我们创建高并发、可伸缩、高容错的分布式系统，并不代表它就应当难以使用。同时，Elixir的运行时并没有彻底远离Erlang的哲学。作为一种函数式语言，它的语义与Erlang非常接近。Elixir能够无缝地集成各种Erlang库，因此开发者能够完整地访问整个Erlang生态系统。

InfoQ：在决定直接使用Erlang或Elixir时，这两者有哪些缺陷是开发者需要考虑进去的？

Sa?a：我不认为它们有任何的缺陷。它们所具有的优势主要来自于VM本身，以及已经过充分测试的OTP框架，而你可以从其中任何一门语言中收获这些益处。因此主要的决定因素在于其它的一些附加价值。Elixir加入了一些额外的特性，因此实际上它是一门比起Erlang更加复杂的语言。而这门语言的优势在于它的代码更加简洁，在样板代码方面的负担较少。与之相比，Erlang是一门更为简单的语言，因此所涉及的代码更多，但它也因而显得更为明确。

从我个人来看，Elixir在样板代码的减少与语言的明确性方面找到了一个很好的平衡点。它没有Ruby等语言表面上那么神奇，而仍然提供了各种实用的特性，其中最值得留意的就是元编程与多态性。

InfoQ：创建一个高可用、高容错的并发系统是一项复杂的任务，尤其是从CAP定律的角度来看。要实现这一目标，选择一门合适的语言与运行时环境的重要性有多高？

Sa?a：这实际上取决于个人的观点。人们在各种语言上都实现过大规模的系统，因此不用Erlang也是完全可能的。不过对我来说，问题不仅仅在于是否可能，还在于某个工具能够在多大程度上帮助我们完成这一过程。毕竟，工具的目的就是为我们提供服务。

而这也是为什么我很看重Erlang的一个原因。在我看来，它为系统化地处理编写高可用系统所面临的挑战提供了简单而又非常强大的构建块。它的主要工具是Erlang进程，它让我们能够将工作分解为几千个，乃至上百万个独立的部分。通过使用多个进程，我们就获得了可伸缩性与容错性。它的崩溃传递机制能够让我们有机会处理这些故障：如果某个部分崩溃了，系统中的其它部分会收到它的通知，并进行相应的处理。最后，无共享并发机制能够实现分布式系统，即使在一台独立的机器上也不例外。其实在本质上，通过将整个工作分解为大量隔离的、完全独立的实体（进程），我们已经实现了分布式工作。当然，将系统在多台机器上实现集群仍然不是一件简单的事，毕竟分布式系统在本质上就存在着复杂性。但至少Erlang已经为我们解决了一些低层次的工作，我们可以始终利用相同的基元功能实现协作，即进程与消息传递。因此我们就能够专注于业务上内在的挑战，而不是将大量的精力消耗在低层次的细节上。

总的来说，我认为Erlang能够简化实现高可用性的挑战。你也可以使用Erlang以外的技术应对这些挑战，但很可能会因此付出更多的努力。

InfoQ：Erlang的一个核心思想是使用非常轻量级的进程模型，这使得上下文切换的开销非常低。另一方面，在许多系统中仍然用线程处理可伸缩性，而线程的可伸缩性往往会成为系统的瓶颈。为了避免这种瓶颈，可以使用一个完整的异步模型配合一个小型的线程池，这种做法也有成功案例（这里有一个参考示例）。你能否详细地分析一下Erlang的处理方式与完整的异步方法相比所具有的优势？

Sa?a：我认为Erlang为我们创建高并发的系统提供了一种优秀而整洁的抽象，而任何一种需要持续处理各种不同任务的系统在本质上都是并发的。Erlang的处理方式非常适合于这种类型的问题，你总是可以通过进程来应对各种类型的任务，无论是I/O密集型还是CPU密集型任务，并且你可以信任VM会高效地分派工作。在使用Erlang不太会出现许多顿悟的情况，也不太会搬起石头砸了自己的脚。它能够让减轻我们的负担，让我们专注于实际的业务问题。

反之，如果你打算自行设计一种线程池，那么就不得不自己处理许多问题。打个比方，如果你在某个线程中执行一个时间很长的计算，那么你会阻塞在同一个线程上挂起的其它活动。如果某个线程因为一个bug而产生故障，该线程上运行的所有活动都会失败。这一点当然是能够解决的，但你或许要为投入大量的时间，以实现一种类似于Erlang VM的功能。既然如此，为什么不依赖于某个已被证实的解决方案呢？如果单纯的处理速度或是内存占用确实极端重要，那么采取自定义的实现方案可能还有一些益处，但在我所遇到的这些情形中来看，基本都不属于这种情况。

InfoQ：Erlang的另一个基本原则也被Elixir保留下来了，那就是“任其崩溃”。这种做法目前已经演变为将例行公事般地干掉进程作为一种确保系统能够容忍这一事件的手段了。这种策略对于打造一个具备容错性的Erlang/Elixir系统有多大的重要性？

Sa?a：Erlang设计的一个前提就是在生产环境中的系统有可能产生错误，但系统作为一个整体不能够中止：它应当尽力保留所有的服务，并尽快地从故障中进行自我修复。

任其崩溃在这种场合扮演了一个核心角色，它是一种简单的技术，能够让我们以一种有条不紊的方式处理系统的错误。在这种情形下，我们会选择让进程崩溃，并依靠Supervisor修复问题。这种做法的好处是该进程的主体代码可以不必操心错误处理的问题，例如编写try-catch或“if err != nil”这样的代码块，而只关注主路径上的逻辑。我们甚至还可以通过模式匹配的方式优雅地对各种期望进行断言。

在我看来，这种方式比try-catch-ignore的做法更优秀，因为一旦进程中止，它的状态也就消失了。而问题的根源很可能来自于有问题的状态。在进程重启之后，新的进程会生成全新的、稳定的状态，因此进程能够再次运转。至少它可以稳定地运行一段时间，直到状态再次出现问题为止。这种做法能够让系统中有问题的地方浮现出来，多数服务在这种方式下都会表现出偶尔的故障现象，直至问题的根源解决为止。

与任其崩溃相辅相成的一点是通过Supervisor进行恢复。如果你建立了一个细粒度的supervision树，那么所需重启的部分也相对较少。一旦产生故障，你可以试着重启系统中的一小部分如果问题仍然没有解决，你可以逐渐增加这部分的区域，直到系统中有问题的那部分被重启为止。相反，如果你采用了try-catch-ignore方式，就有可能导致错误的状态始终延续，最终产生了一个永无休止的故障循环。

InfoQ：“任其崩溃”是仅属于Erlang的一种独特功能吗？可否将其移植至其它不使用Erlang VM的环境中呢？

Sa?a：问得好！首先我要强调一点，OTP是用纯粹的Erlang构建的，它依赖于Erlang VM的基础功能。理解这一点非常重要，因为我曾经看到过一些说法，认为OTP能够以某种方式“移植”到其它运行时环境中。但我认为这是不太可能的，除非目标运行时平台能够提供一些严格的保障。

具体到任其崩溃和supervisor来说， Erlang的VM为它们提供了一些重要的保障。

1. 每个进程的状态都是私有的，一旦进程中止，它不会留下任何垃圾状态，从而也不会干扰其它的进程。
2. 当一个单一的进程崩溃时，其它进程不会受到影响，它们的运行不会被打断，除非你有意这么做。
3. 其它进程能够收到某个进程崩溃的通知，并进行一些相应的处理。
4. 可以无条件地中止一个进程（即使是进程正在进行一个密集的CPU运算）。
5. 进程可以拥有外部资源（例如文件句柄或socket），一旦进程中止，它所拥有的资源会自动回收。

前两点特性能够帮助我们将故障的后果局限在一定范围内：如果有部分出现问题，整个系统的大部分依然能够继续提供服务。第三点保障能够让我们对某个故障进行响应，当发生崩溃时，Supervisor能够对其进行纠正。最后两点保证了适当的系统清理，如果没有这两点保障，系统可能会产生孤儿进程或是资源无法释放的问题。

如果缺乏这些保障，我认为是无法实现Erlang的容错性能力的。即使你能够尽力接近，但永远也做不到100%的功能，总会有些隐秘的功能是你无法察觉的。这并不是说你必须要使用Erlang VM才能够实现任其崩溃的做法，只是说你需要一种能够提供这些保障的VM。

InfoQ：你是否能够分享一下你对于Elixir目前在业界的使用情况的展望？

Sa?a：虽然Elixir还是一门新生的语言，但它的基础（Erlang）已经非常稳定，其能力近20年来在各种不同的大型系统中都得到了证实。成功的案例包括WhatsApp、RabbitMQ、Riak、实时竞价（AdRoll），以及财务系统（Klarna）等等。至于Elixir，我已经看到它越来越多地出现在各种解决方案的生产环境中，例如游戏的后台或物联网（IoT）。可以在这里找到在生产环境中使用Elixir的公司的一个列表，我很期待看到它今后的发展。

关于本书作者

Sa?a Juri?是一位软件开发者，他在使用Elixir和Erlang打造高负载、高并发的服务端系统方面具有丰富的经验。