mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-07 22:11:09 +08:00
60 lines
10 KiB
Markdown
60 lines
10 KiB
Markdown
ESR：最合理的语言工程模式
|
||
============================================================
|
||
|
||
当你熟练掌握一体化工程技术时，你就会发现它逐渐超过了技术优化的层面。我们制作的每件手工艺品都在一个大环境背景下，在这个环境中，人类的行为逐渐突破了经济意义、社会学意义，达到了奥地利经济学家所称的“<ruby>人类行为学<rt>praxeology</rt></ruby>”，这是目的明确的人类行为所能达到的最大范围。
|
||
|
||
对我来说这并不只是抽象理论。当我在开源开发项目中编写论文时，我的行为就十分符合人类行为学的理论，这行为不是针对任何特定的软件技术或某个客观事物，它指的是在开发科技的过程中人类行为的背景环境。从人类行为学角度对科技进行的解读不断增加，大量的这种解读可以重塑科技框架，带来人类生产力和满足感的极大幅度增长，而这并不是由于我们换了工具，而是在于我们改变了掌握它们的方式。
|
||
|
||
在这个背景下，我的计划之外的文章系列的第三篇中谈到了 C 语言的衰退和正在到来的巨大改变，而我们也确实能够感受到系统编程的新时代的到来，在这个时刻，我决定把我之前有的大体的预感具象化为更加具体的、更实用的想法，它们主要是关于计算机语言设计的分析，例如为什么它们会成功，或为什么它们会失败。
|
||
|
||
在我最近的一篇文章中，我写道：所有计算机语言都是对机器资源的成本和程序员工作成本的相对权衡的结果，和对其相对价值的体现。这些都是在一个计算能力成本不断下降但程序员工作成本不减反增的背景下产生的。我还强调了转化成本在使原有交易主张适用于当下环境中的新增角色。在文中我将编程人员描述为一个寻找今后最适方案的探索者。
|
||
|
||
现在我要讲一讲最后一点。以现有水平为起点，一个语言工程师有极大可能通过多种方式推动语言设计的发展。通过什么系统呢？ GC 还是人工分配？使用何种配置，命令式语言、函数程式语言或是面向对象语言？但是从人类行为学的角度来说，我认为它的形式会更简洁，也许只是选择解决长期问题还是短期问题？
|
||
|
||
所谓的“远”、“近”之分，是指硬件成本的逐渐降低，软件复杂程度的上升和由现有语言向其他语言转化的成本的增加，根据它们的变化曲线所做出的判断。短期问题指编程人员眼下发现的问题，长期问题指可预见的一系列情况，但它们一段时间内不会到来。针对近期问题所做出的部署需要非常及时且有效，但随着情况的变化，短期解决方案有可能很快就不适用了。而长期的解决方案可能因其过于超前而夭折，或因其代价过高无法被接受。
|
||
|
||
在计算机刚刚面世的时候， FORTRAN 是近期亟待解决的问题， LISP 是远期问题，汇编语言是短期解决方案。说明这种分类适用于非通用语言，还有 roff 标记语言。随着计算机技术的发展，PHP 和 Javascript 逐渐参与到这场游戏中。至于长期的解决方案？ Oberon、Ocaml、ML、XML-Docbook 都可以。 它们形成的激励机制带来了大量具有突破性和原创性的想法，事态蓬勃但未形成体系，那个时候距离专业语言的面世还很远，（值得注意的是这些想法的出现都是人类行为学中的因果，并非由于某种技术）。专业语言会失败，这是显而易见的，它的转入成本高昂，让大部分人望而却步，因此不能达到能够让主流群体接受的水平，被孤立，被搁置。这也是 LISP 不为人知的的过去，作为前 LISP 管理层人员，出于对它深深的爱，我为你们讲述了这段历史。
|
||
|
||
如果短期解决方案出现故障，它的后果更加惨不忍睹，最好的结果是期待一个相对体面的失败，好转换到另一个设计方案。（通常在转化成本较高时）如果他们执意继续，通常造成众多方案相互之间藕断丝连，形成一个不断扩张的复合体，一直维持到不能运转下去，变成一堆摇摇欲坠的杂物。是的，我说的就是 C++ 语言，还有 Java 描述语言，（唉）还有 Perl，虽然 Larry Wall 的好品味成功地让他维持了很多年，问题一直没有爆发，但在 Perl 6 发行时，他的好品味最终引爆了整个问题。
|
||
|
||
这种思考角度激励了编程人员向着两个不同的目的重新塑造语言设计: （1）以远近为轴，在自身和预计的未来之间选取一个最适点，然后（2）降低由一种或多种语言转化为自身语言的转入成本，这样你就可以吸纳他们的用户群。接下来我会讲讲 C 语言是怎样占领全世界的。
|
||
|
||
在整个计算机发展史中，没有谁能比 C 语言完美地把握最适点的选取了，我要做的只是证明这一点，作为一种实用的主流语言， C 语言有着更长的寿命，它目睹了无数个竞争者的兴衰，但它的地位仍旧不可取代。从淘汰它的第一个竞争者到现在已经过了 35 年，但看起来C语言的终结仍旧不会到来。
|
||
|
||
当然，如果你愿意的话，可以把 C 语言的持久存在归功于人类的文化惰性，但那是对“文化惰性”这个词的曲解， C 语言一直得以延续的真正原因是没有人提供足够的转化费用！
|
||
|
||
相反的， C 语言低廉的内部转化成本未得到应有的重视，C 语言是如此的千变万化，从它漫长统治时期的初期开始，它就可以适用于多种语言如 FORTRAN、Pascal 、汇编语言和 LISP 的编程习惯。在二十世纪八十年代我就注意到，我可以根据编程人员的编码风格判断出他的母语是什么，这也从另一方面证明了C 语言的魅力能够吸引全世界的人使用它。
|
||
|
||
C++ 语言同样胜在它低廉的转化成本。很快，大部分新兴的语言为了降低自身转化成本，纷纷参考 C 语言语法。请注意这给未来的语言设计环境带来了什么影响：它尽可能地提高了类 C 语言的价值，以此来降低其他语言转化为 C 语言的转化成本。
|
||
|
||
另一种降低转入成本的方法十分简单，即使没接触过编程的人都能学会，但这种方法很难完成。我认为唯一使用了这种方法的 Python 就是靠这种方法进入了职业比赛。对这个方法我一带而过，是因为它并不是我希望看到的，顺利执行的系统语言战略，虽然我很希望它不是那样的。
|
||
|
||
今天我们在 2017 年底聚集在这里，下一项我们应该为某些暴躁的团体发声，如 Go 团队，但事实并非如此。 Go 这个项目漏洞百出，我甚至可以想象出它失败的各种可能，Go 团队太过固执独断，即使几乎整个用户群体都认为 Go 需要做出改变了，Go 团队也无动于衷，这是个大问题。 一旦发生故障， GC 发生延迟或者用牺牲生产量来弥补延迟，但无论如何，它都会严重影响到这种语言的应用，大幅缩小这种语言的适用范围。
|
||
|
||
即便如此，在 Go 的设计中，还是有一个我颇为认同的远大战略目标，想要理解这个目标，我们需要回想一下如果想要取代 C 语言，要面临的短期问题是什么。同我之前提到的，随着项目计划的不断扩张，故障率也在持续上升，这其中内存管理方面的故障尤其多，而内存管理一直是崩溃漏洞和安全漏洞的高发领域。
|
||
|
||
我们现在已经知道了两件十分重要的紧急任务，要想取代 C 语言，首先要先做到这两点：（1）解决内存管理问题；（2）降低由 C 语言向本语言转化时所需的转入成本。纵观编程语言的历史——从人类行为学的角度来看，作为 C 语言的准替代者，如果不能有效解决转入成本过高这个问题，那他们所做的其他部分做得再好都不算数。相反的，如果他们把转入成本过高这个问题解决地很好，即使他们其他部分做的不是最好的，人们也不会对他们吹毛求疵。
|
||
|
||
这正是 Go 的做法，但这个理论并不是完美无瑕的，它也有局限性。目前 GC 延迟限制了它的发展，但 Go 现在选择照搬 Unix 下 C 语言的传染战略，让自身语言变成易于转入，便于传播的语言，其繁殖速度甚至快于替代品。但从长远角度看，这并不是个好办法。
|
||
|
||
当然， Rust 语言的不足是个十分明显的问题，我们不应当回避它。而它，正将自己定位为适用于长远计划的选择。在之前的部分中我已经谈到了为什么我觉得它还不完美，Rust 语言在 TIBOE 和PYPL 指数上的成就也证明了我的说法，在 TIBOE 上 Rust 从来没有进过前 20 名，在 PYPL 指数上它的成就也比 Go 差很多。
|
||
|
||
五年后 Rust 能发展的怎样还是个问题，如果他们愿意改变，我建议他们重视转入成本问题。以我个人经历来说，由 C 语言转入 Rust 语言的能量壁垒使人望而却步。如果编码提升工具比如 Corrode 只能把 C 语言映射为不稳定的 Rust 语言，但不能解决能量壁垒的问题；或者如果有更简单的方法能够自动注释所有权或试用期，人们也不再需要它们了——这些问题编译器就能够解决。目前我不知道怎样解决这个问题，但我觉得他们最好找出解决方案。
|
||
|
||
在最后我想强调一下，虽然在 Ken Thompson 的设计经历中，他看起来很少解决短期问题，但他对未来有着极大的包容性，并且这种包容性还在不断提升。当然 Unix 也是这样的， 它让我不禁暗自揣测，让我认为 Go 语言中令人不快的地方都其实是他们未来事业的基石（例如缺乏泛型）。如果要确认这件事是真假，我需要比 Ken 还要聪明，但这并不是一件容易让人相信的事情。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: http://esr.ibiblio.org/?p=7745
|
||
|
||
作者：[Eric Raymond][a]
|
||
译者：[Valoniakim](https://github.com/Valoniakim)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:http://esr.ibiblio.org/?author=2
|
||
[1]:http://esr.ibiblio.org/?author=2
|
||
[2]:http://esr.ibiblio.org/?p=7711&cpage=1#comment-1913931
|
||
[3]:http://esr.ibiblio.org/?p=7745
|