From 2c5fb5bee220428392f6a694a75d6b0730832417 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Thu, 21 Dec 2017 19:11:37 +0800 Subject: [PATCH 1/3] =?UTF-8?q?20171118=20=E6=A0=A1=E5=AF=B9=E5=AE=8C?= =?UTF-8?q?=E6=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ... Language engineering for great justice.md | 48 +++++++++---------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/translated/tech/20171118 Language engineering for great justice.md b/translated/tech/20171118 Language engineering for great justice.md index fc116e2e18..97f44dcfe0 100644 --- a/translated/tech/20171118 Language engineering for great justice.md +++ b/translated/tech/20171118 Language engineering for great justice.md @@ -1,55 +1,55 @@ -ESR：最合理的语言工程模式 +ESR：程序语言设计的真谛 ============================================================ -当你熟练掌握一体化工程技术时，你就会发现它逐渐超过了技术优化的层面。我们制作的每件手工艺品都在一个大环境背景下，在这个环境中，人类的行为逐渐突破了经济意义、社会学意义，达到了奥地利经济学家所称的“人类行为学praxeology”，这是目的明确的人类行为所能达到的最大范围。 +当你真正掌握了整体化的工程设计思维时，你就会发现高屋建瓴的工程设计已经远远超越了技术优化的层面。我们的每一件创造都催生于人类活动的大背景下，被这种人类活动赋予了广泛的经济学意义、社会学意义，甚至于具有了奥地利经济学家所称的“人类行为学意义praxeology”。而这种人类行为学意义则是明确的人类行为所能达到的最高层次。 -对我来说这并不只是抽象理论。当我在开源开发项目中编写论文时，我的行为就十分符合人类行为学的理论，这行为不是针对任何特定的软件技术或某个客观事物，它指的是在开发科技的过程中人类行为的背景环境。从人类行为学角度对科技进行的解读不断增加，大量的这种解读可以重塑科技框架，带来人类生产力和满足感的极大幅度增长，而这并不是由于我们换了工具，而是在于我们改变了掌握它们的方式。 +对我来说这并不只是一种抽象的理论。当我在撰写关于开源项目开发的文章时，文章的内容正是关于人类行为学的 - 这些文章并不涉及哪个具体的软件技术或者话题，而是在讨论科技所服务的人类行为。从人类行为学角度对科技进行更深入的理解，可以帮助我们重塑科技，并且提升我们的生产力和成就感。这种提升并不总是因为我们有了更新的工具，而更多的是因为我们改变了使用现有工具的思路，提升了我们对这些工具的驾驭能力。 -在这个背景下，我的计划之外的文章系列的第三篇中谈到了 C 语言的衰退和正在到来的巨大改变，而我们也确实能够感受到系统编程的新时代的到来，在这个时刻，我决定把我之前有的大体的预感具象化为更加具体的、更实用的想法，它们主要是关于计算机语言设计的分析，例如为什么它们会成功，或为什么它们会失败。 +在这个思路之下，我的随笔文章的第三篇中谈到了 C 语言的衰退和正在到来的巨大改变，而我们也确实能够感受到系统级别编程的新时代的到来。在这里，我会把我的统观见解总结成更具体的、更实用的对计算机语言设计的分析。例如总结出为什么一些语言会成功，另一些语言会失败。 -在我最近的一篇文章中，我写道：所有计算机语言都是对机器资源的成本和程序员工作成本的相对权衡的结果，和对其相对价值的体现。这些都是在一个计算能力成本不断下降但程序员工作成本不减反增的背景下产生的。我还强调了转化成本在使原有交易主张适用于当下环境中的新增角色。在文中我将编程人员描述为一个寻找今后最适方案的探索者。 +在我最近的一篇文章中，我写道：所有计算机语言的设计都是对机器资源和程序员人力成本的相对权衡的结果；是对一种相对价值主张的体现。而这些设计思路都是在硬件算力成本不断下降，程序员人力成本相对稳定且可能不减反增的背景下产生的。我还强调了语言设计在实现了一些原有的权衡方案之后，其未来的转化和演变成本在这种语言的成败中所要扮演的一些额外角色。在文中我也阐述了编程语言设计者是如何为当前和可见的未来寻找新的最优设计方案的。 -现在我要讲一讲最后一点。以现有水平为起点，一个语言工程师有极大可能通过多种方式推动语言设计的发展。通过什么系统呢？ GC 还是人工分配？使用何种配置，命令式语言、函数程式语言或是面向对象语言？但是从人类行为学的角度来说，我认为它的形式会更简洁，也许只是选择解决长期问题还是短期问题？ +现在我要集中讲解一下我在上面段落里最后提到的那个概念，即语言设计工程师们其实可以在多个方面来改进和提高现阶段编程语言的设计水准。比如输入系统的优化，GC (垃圾回收机制) 和手动内存分配的权衡，命令导向、函数导向和面向对象导向的混合和权衡。但是站在人类行为学的角度去考量，我认为设计师们一定会做出更简单的设计权衡，即针对近景问题还是针对远景问题来优化一种语言的设计。 -所谓的“远”、“近”之分，是指硬件成本的逐渐降低，软件复杂程度的上升和由现有语言向其他语言转化的成本的增加，根据它们的变化曲线所做出的判断。短期问题指编程人员眼下发现的问题，长期问题指可预见的一系列情况，但它们一段时间内不会到来。针对近期问题所做出的部署需要非常及时且有效，但随着情况的变化，短期解决方案有可能很快就不适用了。而长期的解决方案可能因其过于超前而夭折，或因其代价过高无法被接受。 +所谓的“远”、“近”之分，是指随着硬件成本的逐渐降低，软件复杂程度的上升和由现有语言向其他语言转化的成本的增加，根据这些因素的变化曲线所做出的判断。近景问题是编程人员眼下看到的问题，远景问题则是指可预见的，但未必会很快到来的一系列情况。针对近景问题的解决方案可以被很快部署下去，且能够在短期内非常有效，但随着情况的变化和时间的推移，这种方案可能很快就不适用了。而远景的解决方案可能因为其自身的复杂和超前性而夭折，或是因其代价过高无法被接受和采纳。 -在计算机刚刚面世的时候， FORTRAN 是近期亟待解决的问题， LISP 是远期问题，汇编语言是短期解决方案。说明这种分类适用于非通用语言，还有 roff 标记语言。随着计算机技术的发展，PHP 和 Javascript 逐渐参与到这场游戏中。至于长期的解决方案？ Oberon、Ocaml、ML、XML-Docbook 都可以。 它们形成的激励机制带来了大量具有突破性和原创性的想法，事态蓬勃但未形成体系，那个时候距离专业语言的面世还很远，（值得注意的是这些想法的出现都是人类行为学中的因果，并非由于某种技术）。专业语言会失败，这是显而易见的，它的转入成本高昂，让大部分人望而却步，因此不能达到能够让主流群体接受的水平，被孤立，被搁置。这也是 LISP 不为人知的的过去，作为前 LISP 管理层人员，出于对它深深的爱，我为你们讲述了这段历史。 +在计算机刚刚面世的时候， FORTRAN 就是一个近景设计方案， LISP 语言的设计则是针对远景问题; 汇编语言多是近景设计方案，很好的阐明了这类设计很适用于非通用语言，同样的例子还包括 ROFF 标记语言。PHP 和 Javascript 则是我们后来看到的采用了近景设计思维的语言。那么后来的远景设计方案有哪些例子呢？ Oberon、Ocaml、ML、XML-Docbook 都是它的例子。学术研究中设计出的语言多倾向于远景设计，因为在学术研究领域，原创性以及大胆的假设与想法是很重要的。这和学术研究的动机以及其奖励机制很有关系（值得注意的是，在学术研究中，倾向于远景设计的本源动机并非出于技术方面的原因，而是出自于人类行为，即标新立异才能在学术上有成绩）。学术研究中设计出的编程语言是注定会失败的; 因为学术研究的产物常常有高昂的转入成本，无人问津的设计。这类语言也因为在社区中不够流行而不能得到主流的采纳，具有孤立性，且常常被搁置成为半成品。（如上所述的问题正是对 LISP 历史的精辟总结，而且我是以一个对 LISP 语言有深入研究，并深深喜爱它的使用者的身份来评价 LISP 的）。 -如果短期解决方案出现故障，它的后果更加惨不忍睹，最好的结果是期待一个相对体面的失败，好转换到另一个设计方案。（通常在转化成本较高时）如果他们执意继续，通常造成众多方案相互之间藕断丝连，形成一个不断扩张的复合体，一直维持到不能运转下去，变成一堆摇摇欲坠的杂物。是的，我说的就是 C++ 语言，还有 Java 描述语言，（唉）还有 Perl，虽然 Larry Wall 的好品味成功地让他维持了很多年，问题一直没有爆发，但在 Perl 6 发行时，他的好品味最终引爆了整个问题。 +一些近景设计的失败案例则更加惨不忍睹。对这些案例来说，我们能够期待的最好的结果就是这种语言可以消亡的相对体面一些，被一种新的语言设计取而代之。如果这些近景设计导向的语言没有死亡而是一直被沿用下去（通常是因为转化成本过高），那么我们则会看到不断有新的特性和功能在这些语言原来的基础之上堆积起来，以保持他们的可用性和有效性。直到这种堆积把这些语言变得越来越复杂，变的危若累卵且不可理喻。是的，我说的就是 C++ 。当然， 还有 Javascript. Perl 也不例外，尽管它的设计者 Larry Walls 有不错的设计品味，避免了很多问题，让这种语言得以存活了很多年。但也正是因为 Larry Walls 的好品味，让他在最终对 Perl 的固有问题忍无可忍之后发布了全新的 Perl 6。 -这种思考角度激励了编程人员向着两个不同的目的重新塑造语言设计: （1）以远近为轴，在自身和预计的未来之间选取一个最适点，然后（2）降低由一种或多种语言转化为自身语言的转入成本，这样你就可以吸纳他们的用户群。接下来我会讲讲 C 语言是怎样占领全世界的。 +从这种角度去思考程序语言，我们则可以把语言设计中需要侧重的目标重新归纳为两部分: （1）以时间的远近为轴，在远景设计和近景设计之间选取一个符合预期的最佳平衡点；（2）降低由一种或多种语言转化为这种新语言的转入成本，这样就可以更好地吸纳其它语言的用户群。接下来我会讲讲 C 语言是怎样占领全世界的。 -在整个计算机发展史中，没有谁能比 C 语言完美地把握最适点的选取了，我要做的只是证明这一点，作为一种实用的主流语言， C 语言有着更长的寿命，它目睹了无数个竞争者的兴衰，但它的地位仍旧不可取代。从淘汰它的第一个竞争者到现在已经过了 35 年，但看起来C语言的终结仍旧不会到来。 +在整个计算机发展史中，没有谁能比 C 语言 在选择远景和近景设计的平衡点的时候做的更完美。事实胜于雄辩，作为一种实用的主流语言，C 语言有着很长的寿命，它目睹了无数个竞争者的兴衰，但它的地位仍旧不可取代。从淘汰它的第一个竞争者到现在已经过了 35 年，但看起来C语言的终结仍旧不会到来。 -当然，如果你愿意的话，可以把 C 语言的持久存在归功于人类的文化惰性，但那是对“文化惰性”这个词的曲解， C 语言一直得以延续的真正原因是没有人提供足够的转化费用！ +当然，你可以把 C 语言的持久存在归功于文化惰性，但那是对“文化惰性”这个词的曲解，C 语言一直得以延续的真正原因是因为目前还没有人能提供另一种足够好的语言，可以抵消取代 C 语言所需要的转化成本！ -相反的， C 语言低廉的内部转化成本未得到应有的重视，C 语言是如此的千变万化，从它漫长统治时期的初期开始，它就可以适用于多种语言如 FORTRAN、Pascal 、汇编语言和 LISP 的编程习惯。在二十世纪八十年代我就注意到，我可以根据编程人员的编码风格判断出他的母语是什么，这也从另一方面证明了C 语言的魅力能够吸引全世界的人使用它。 +相反的，C 语言低廉的内向转化成本（转入成本）并未引起大家应有的重视，C 语言几乎是唯一的一个极其多样和强大的编程工具，以至于从它漫长统治时期的初期开始，它就可以适用于多种语言如 FORTRAN、Pascal 、汇编语言和 LISP 的编程习惯。在一九八零年代我就注意到，我常常可以根据一个 C 语言新人的编码风格判断出他之前在使用什么语言，这也从另一方面证明了 C 语言可以轻松的被其它语言的使用者所接受，并吸引他们加入进来。 -C++ 语言同样胜在它低廉的转化成本。很快，大部分新兴的语言为了降低自身转化成本，纷纷参考 C 语言语法。请注意这给未来的语言设计环境带来了什么影响：它尽可能地提高了类 C 语言的价值，以此来降低其他语言转化为 C 语言的转化成本。 +C++ 语言同样胜在它低廉的转化成本。很快，大部分新兴的语言为了降低自身的转入成本，都纷纷参考了 C 语言的语法。值得注意的是这给未来的语言设计带来了一种影响：即新语言的设计都在尽可能的向 C 的语法靠拢，以便这种新语言可以有很低的内向转化成本（转入成本），使其他语言的使用者可以欣然接受并使用这种新语言。 -另一种降低转入成本的方法十分简单，即使没接触过编程的人都能学会，但这种方法很难完成。我认为唯一使用了这种方法的 Python 就是靠这种方法进入了职业比赛。对这个方法我一带而过，是因为它并不是我希望看到的，顺利执行的系统语言战略，虽然我很希望它不是那样的。 +另一种降低转入成本的方法则是把一种编程语言设计的极其简单并容易入手，让那些即使是没有编程经验的人都可以轻松学会。但做到这一点并非易事。我认为只有一种语言 - Python - 成功的做到了这一点，即通过易用的设计来降低内向转化成本。对这种程序语言的设计思路我在这里一带而过，因为我并不认为一种系统级别的语言可以被设计的像 Python 一样傻瓜易用，当然我很希望我的这个论断是错的。 -今天我们在 2017 年底聚集在这里，下一项我们应该为某些暴躁的团体发声，如 Go 团队，但事实并非如此。 Go 这个项目漏洞百出，我甚至可以想象出它失败的各种可能，Go 团队太过固执独断，即使几乎整个用户群体都认为 Go 需要做出改变了，Go 团队也无动于衷，这是个大问题。 一旦发生故障， GC 发生延迟或者用牺牲生产量来弥补延迟，但无论如何，它都会严重影响到这种语言的应用，大幅缩小这种语言的适用范围。 +而今我们已经来到 2017 年末尾，你一定猜测我接下来会向那些 Go 语言的鼓吹者一样对 Go 大加赞赏一番，然后激怒那些对 Go 不厌其烦的人群。但其实我的观点恰恰相反，我认为 Go 本身很有可能在许多方面遭遇失败。Go 团队太过固执独断，即使几乎整个用户群体都认为 Go 需要做出某些方面的改变了，Go 团队也无动于衷，这是个大问题。目前，Go 语言的 GC 延迟问题以及用以平衡延迟而牺牲掉的吞吐量，都可能会严重制约这种语言的适用范围。 -即便如此，在 Go 的设计中，还是有一个我颇为认同的远大战略目标，想要理解这个目标，我们需要回想一下如果想要取代 C 语言，要面临的短期问题是什么。同我之前提到的，随着项目计划的不断扩张，故障率也在持续上升，这其中内存管理方面的故障尤其多，而内存管理一直是崩溃漏洞和安全漏洞的高发领域。 +即便如此，在 Go 的设计中还是蕴含了一个让我颇为认同的远大战略目标。想要理解这个目标，我们需要回想一下如果想要取代 C 语言，要面临的短期问题是什么。正如我之前提到的，这个问题就是，随着软件工程项目和系统的不断扩张，故障率也在持续上升，这其中内存管理方面的故障尤其多，而内存管理故障一直是导致系统崩溃和安全漏洞的主要元凶。 -我们现在已经知道了两件十分重要的紧急任务，要想取代 C 语言，首先要先做到这两点：（1）解决内存管理问题；（2）降低由 C 语言向本语言转化时所需的转入成本。纵观编程语言的历史——从人类行为学的角度来看，作为 C 语言的准替代者，如果不能有效解决转入成本过高这个问题，那他们所做的其他部分做得再好都不算数。相反的，如果他们把转入成本过高这个问题解决地很好，即使他们其他部分做的不是最好的，人们也不会对他们吹毛求疵。 +我们现在已经认清，一种语言要想取代 C 语言，它的设计就必须遵循两个十分重要准则：（1）解决内存管理问题；（2）降低由 C 语言向本语言转化时所需的转入成本。从人类行为学的角度来纵观编程语言的历史，我们不难发现，作为 C 语言的准替代者，如果不能有效解决转入成本过高这个问题，那设计者所做的其他部分做得再好都不算数。相反的，如果一种 C 的替代语言把转入成本过高这个问题解决地很好，即使它在其他部分做的不是最好的，人们也不会对这种语言吹毛求疵。 -这正是 Go 的做法，但这个理论并不是完美无瑕的，它也有局限性。目前 GC 延迟限制了它的发展，但 Go 现在选择照搬 Unix 下 C 语言的传染战略，让自身语言变成易于转入，便于传播的语言，其繁殖速度甚至快于替代品。但从长远角度看，这并不是个好办法。 +而 Go 正是遵循了上述两点设计思路，虽然这个思路并不是一种完美无瑕的设计理论，也有其局限性。比如，目前 GC 延迟的问题就限制了 Go 的推广。但是 Go 目前选择了照搬 Unix 下 C 语言的传染战略，把其自身设计成一种易于转入，便于传播的语言。这样它的广泛和快速的传播就会使其迅速占领市场，从而打败那些针对远景设计的看起来更好的语言。 -当然， Rust 语言的不足是个十分明显的问题，我们不应当回避它。而它，正将自己定位为适用于长远计划的选择。在之前的部分中我已经谈到了为什么我觉得它还不完美，Rust 语言在 TIBOE 和PYPL 指数上的成就也证明了我的说法，在 TIBOE 上 Rust 从来没有进过前 20 名，在 PYPL 指数上它的成就也比 Go 差很多。 +当然，我所指的这个远景设计方案就是 Rust。我曾经在之前的一些文章中解释过我为什么认为 Rust 还没有做好和 Go 展开竞争的准备。TIBOE 和 PYPL 的语言评价指数榜也很好的证明了我的对于 Rust 的这个观点。在 TIBOE 上 Rust 从来没有进过前 20 名。而在 TIBOE 和 PYPL 两个指数榜上， Rust 都要比 Go 的表现差很多。 -五年后 Rust 能发展的怎样还是个问题，如果他们愿意改变，我建议他们重视转入成本问题。以我个人经历来说，由 C 语言转入 Rust 语言的能量壁垒使人望而却步。如果编码提升工具比如 Corrode 只能把 C 语言映射为不稳定的 Rust 语言，但不能解决能量壁垒的问题；或者如果有更简单的方法能够自动注释所有权或试用期，人们也不再需要它们了——这些问题编译器就能够解决。目前我不知道怎样解决这个问题，但我觉得他们最好找出解决方案。 +五年后的 Rust 会发展的怎样还未可知。但如果 Rust 社区的开发人员对这种语言的设计抱着认真投入的态度，并愿意倾听，那么我建议他们要特别重视转入成本的问题。以我个人经历来说，目前由 C 语言转入 Rust 语言的壁垒很高，使人望而却步。如果 Corrode 之类的 Code-lifting 工具只是把 C 语言映射为不安全的 Rust 语言，那么 Corrode 这类工具也是不能解决这种转入壁垒的。或者如果有更简单的方法能够自动注释代码的所有权或生命周期，那么编译器就能把 C 代码直接映射到 Rust，人们也不再需要 Corrode 这一类工具了。目前我还不知道这个问题要如何解决，但我觉得 Rust 社区最好能够找到一种解决方案来代替 Corrode 和其同类工具。 -在最后我想强调一下，虽然在 Ken Thompson 的设计经历中，他看起来很少解决短期问题，但他对未来有着极大的包容性，并且这种包容性还在不断提升。当然 Unix 也是这样的， 它让我不禁暗自揣测，让我认为 Go 语言中令人不快的地方都其实是他们未来事业的基石（例如缺乏泛型）。如果要确认这件事是真假，我需要比 Ken 还要聪明，但这并不是一件容易让人相信的事情。 +在最后我想强调一下，Ken Thompson 曾经有过语言设计的辉煌历史。他设计的一些语言虽然看起来只是为了解决近景问题，实际上却具有很高的质量和开放程度，让这些语言同样非常适合远景问题，非常易于被提高和拓展。当然 Unix 也是这样的， 这让我不禁暗自揣测，那些我认为的 Go 语言中乍看上去不利于其远景发展的一些令人担忧烦扰的设计（例如缺乏泛型）也许并没有我想象的那样糟糕。如果确如我所认为的那样，即这些设计会影响 Go 的远景发展，那么恐怕我真的是比 Ken 还要聪明有远见了。但是我并不认为我有那么高明。Go 的前途我们还是只能拭目以待。 -------------------------------------------------------------------------------- via: http://esr.ibiblio.org/?p=7745 作者：[Eric Raymond][a] -译者：[Valoniakim](https://github.com/Valoniakim) -校对：[wxy](https://github.com/wxy) +译者：[Valoniakim](https://github.com/Valoniakim)，[yunfengHe](https://github.com/yunfengHe) +校对：[yunfengHe](https://github.com/yunfengHe)，[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From e847a5a0b35bb1f106ab781b146c83985f0b6d34 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Thu, 21 Dec 2017 19:20:25 +0800 Subject: [PATCH 2/3] =?UTF-8?q?20171118=20=E6=A0=A1=E5=AF=B9=E5=AE=8C?= =?UTF-8?q?=E6=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../tech/20171118 Language engineering for great justice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20171118 Language engineering for great justice.md b/translated/tech/20171118 Language engineering for great justice.md index 97f44dcfe0..2dd4f8a518 100644 --- a/translated/tech/20171118 Language engineering for great justice.md +++ b/translated/tech/20171118 Language engineering for great justice.md @@ -37,7 +37,7 @@ C++ 语言同样胜在它低廉的转化成本。很快，大部分新兴的语 而 Go 正是遵循了上述两点设计思路，虽然这个思路并不是一种完美无瑕的设计理论，也有其局限性。比如，目前 GC 延迟的问题就限制了 Go 的推广。但是 Go 目前选择了照搬 Unix 下 C 语言的传染战略，把其自身设计成一种易于转入，便于传播的语言。这样它的广泛和快速的传播就会使其迅速占领市场，从而打败那些针对远景设计的看起来更好的语言。 -当然，我所指的这个远景设计方案就是 Rust。我曾经在之前的一些文章中解释过我为什么认为 Rust 还没有做好和 Go 展开竞争的准备。TIBOE 和 PYPL 的语言评价指数榜也很好的证明了我的对于 Rust 的这个观点。在 TIBOE 上 Rust 从来没有进过前 20 名。而在 TIBOE 和 PYPL 两个指数榜上， Rust 都要比 Go 的表现差很多。 +当然，我所指的这个远景设计方案就是 Rust。而 Rust 的自身定位也正是一种远景和长期的 C 语言替代方案。我曾经在之前的一些文章中解释过我为什么认为 Rust 还没有做好和 Go 展开竞争的准备。TIBOE 和 PYPL 的语言评价指数榜也很好的证明了我的对于 Rust 的这个观点。在 TIBOE 上 Rust 从来没有进过前 20 名。而在 TIBOE 和 PYPL 两个指数榜上， Rust 都要比 Go 的表现差很多。 五年后的 Rust 会发展的怎样还未可知。但如果 Rust 社区的开发人员对这种语言的设计抱着认真投入的态度，并愿意倾听，那么我建议他们要特别重视转入成本的问题。以我个人经历来说，目前由 C 语言转入 Rust 语言的壁垒很高，使人望而却步。如果 Corrode 之类的 Code-lifting 工具只是把 C 语言映射为不安全的 Rust 语言，那么 Corrode 这类工具也是不能解决这种转入壁垒的。或者如果有更简单的方法能够自动注释代码的所有权或生命周期，那么编译器就能把 C 代码直接映射到 Rust，人们也不再需要 Corrode 这一类工具了。目前我还不知道这个问题要如何解决，但我觉得 Rust 社区最好能够找到一种解决方案来代替 Corrode 和其同类工具。 From 90ce6f17143614bed143944ee974d41737fa9290 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Thu, 21 Dec 2017 19:32:59 +0800 Subject: [PATCH 3/3] =?UTF-8?q?20171118=20=E6=A0=A1=E5=AF=B9=E5=AE=8C?= =?UTF-8?q?=E6=AF=95=EF=BC=8C=E9=A2=98=E7=9B=AE=E9=87=8D=E8=AF=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../tech/20171118 Language engineering for great justice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20171118 Language engineering for great justice.md b/translated/tech/20171118 Language engineering for great justice.md index 2dd4f8a518..2da49da481 100644 --- a/translated/tech/20171118 Language engineering for great justice.md +++ b/translated/tech/20171118 Language engineering for great justice.md @@ -1,4 +1,4 @@ -ESR：程序语言设计的真谛 +ESR：程序语言设计的要诣和真谛 ============================================================ 当你真正掌握了整体化的工程设计思维时，你就会发现高屋建瓴的工程设计已经远远超越了技术优化的层面。我们的每一件创造都催生于人类活动的大背景下，被这种人类活动赋予了广泛的经济学意义、社会学意义，甚至于具有了奥地利经济学家所称的“人类行为学意义praxeology”。而这种人类行为学意义则是明确的人类行为所能达到的最高层次。