mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Wenxuan Zhao
commit
c12dc748f2
@ -1,60 +0,0 @@
|
||||
Translating by ValoniaKim
|
||||
Language engineering for great justice
|
||||
============================================================
|
||||
|
||||
Whole-systems engineering, when you get good at it, goes beyond being entirely or even mostly about technical optimizations. Every artifact we make is situated in a context of human action that widens out to the economics of its use, the sociology of its users, and the entirety of what Austrian economists call “praxeology”, the science of purposeful human behavior in its widest scope.
|
||||
|
||||
This isn’t just abstract theory for me. When I wrote my papers on open-source development, they were exactly praxeology – they weren’t about any specific software technology or objective but about the context of human action within which technology is worked. An increase in praxeological understanding of technology can reframe it, leading to tremendous increases in human productivity and satisfaction, not so much because of changes in our tools but because of changes in the way we grasp them.
|
||||
|
||||
In this, the third of my unplanned series of posts about the twilight of C and the huge changes coming as we actually begin to see forward into a new era of systems programming, I’m going to try to cash that general insight out into some more specific and generative ideas about the design of computer languages, why they succeed, and why they fail.
|
||||
|
||||
In my last post I noted that every computer language is an embodiment of a relative-value claim, an assertion about the optimal tradeoff between spending machine resources and spending programmer time, all of this in a context where the cost of computing power steadily falls over time while programmer-time costs remain relatively stable or may even rise. I also highlighted the additional role of transition costs in pinning old tradeoff assertions into place. I described what language designers do as seeking a new optimum for present and near-future conditions.
|
||||
|
||||
Now I’m going to focus on that last concept. A language designer has lots of possible moves in language-design space from where the state of the art is now. What kind of type system? GC or manual allocation? What mix of imperative, functional, or OO approaches? But in praxeological terms his choice is, I think, usually much simpler: attack a near problem or a far problem?
|
||||
|
||||
“Near” and “far” are measured along the curves of falling hardware costs, rising software complexity, and increasing transition costs from existing languages. A near problem is one the designer can see right in front of him; a far problem is a set of conditions that can be seen coming but won’t necessarily arrive for some time. A near solution can be deployed immediately, to great practical effect, but may age badly as conditions change. A far solution is a bold bet that may smother under the weight of its own overhead before its future arrives, or never be adopted at all because moving to it is too expensive.
|
||||
|
||||
Back at the dawn of computing, FORTRAN was a near-problem design, LISP a far-problem one. Assemblers are near solutions. Illustrating that the categories apply to non-general-purpose languages, also roff markup. Later in the game, PHP and Javascript. Far solutions? Oberon. Ocaml. ML. XML-Docbook. Academic languages tend to be far because the incentive structure around them rewards originality and intellectual boldness (note that this is a praxeological cause, not a technical one!). The failure mode of academic languages is predictable; high inward transition costs, nobody goes there, failure to achieve community critical mass sufficient for mainstream adoption, isolation, and stagnation. (That’s a potted history of LISP in one sentence, and I say that as an old LISP-head with a deep love for the language…)
|
||||
|
||||
The failure modes of near designs are uglier. The best outcome to hope for is a graceful death and transition to a newer design. If they hang on (most likely to happen when transition costs out are high) features often get piled on them to keep them relevant, increasing complexity until they become teetering piles of cruft. Yes, C++, I’m looking at you. You too, Javascript. And (alas) Perl, though Larry Wall’s good taste mitigated the problem for many years – but that same good taste eventually moved him to blow up the whole thing for Perl 6.
|
||||
|
||||
This way of thinking about language design encourages reframing the designer’s task in terms of two objectives. (1) Picking a sweet spot on the near-far axis away from you into the projected future; and (2) Minimizing inward transition costs from one or more existing languages so you co-opt their userbases. And now let’s talk about about how C took over the world.
|
||||
|
||||
There is no more more breathtaking example than C than of nailing the near-far sweet spot in the entire history of computing. All I need to do to prove this is point at its extreme longevity as a practical, mainstream language that successfully saw off many competitors for its roles over much of its range. That timespan has now passed about 35 years (counting from when it swamped its early competitors) and is not yet with certainty ended.
|
||||
|
||||
OK, you can attribute some of C’s persistence to inertia if you want, but what are you really adding to the explanation if you use the word “inertia”? What it means is exactly that nobody made an offer that actually covered the transition costs out of the language!
|
||||
|
||||
Conversely, an underappreciated strength of the language was the low inward transition costs. C is an almost uniquely protean tool that, even at the beginning of its long reign, could readily accommodate programming habits acquired from languages as diverse as FORTRAN, Pascal, assemblers and LISP. I noticed back in the 1980s that I could often spot a new C programmer’s last language by his coding style, which was just the flip side of saying that C was damn good at gathering all those tribes unto itself.
|
||||
|
||||
C++ also benefited from having low transition costs in. Later, most new languages at least partly copied C syntax in order to minimize them.Notice what this does to the context of future language designs: it raises the value of being a C-like as possible in order to minimize inward transition costs from anywhere.
|
||||
|
||||
Another way to minimize inward transition costs is to simply be ridiculously easy to learn, even to people with no prior programming experience. This, however, is remarkably hard to pull off. I evaluate that only one language – Python – has made the major leagues by relying on this quality. I mention it only in passing because it’s not a strategy I expect to see a _systems_ language execute successfully, though I’d be delighted to be wrong about that.
|
||||
|
||||
So here we are in late 2017, and…the next part is going to sound to some easily-annoyed people like Go advocacy, but it isn’t. Go, itself, could turn out to fail in several easily imaginable ways. It’s troubling that the Go team is so impervious to some changes their user community is near-unanimously and rightly (I think) insisting it needs. Worst-case GC latency, or the throughput sacrifices made to lower it, could still turn out to drastically narrow the language’s application range.
|
||||
|
||||
That said, there is a grand strategy expressed in the Go design that I think is right. To understand it, we need to review what the near problem for a C replacement is. As I noted in the prequels, it is rising defect rates as systems projects scale up – and specifically memory-management bugs because that category so dominates crash bugs and security exploits.
|
||||
|
||||
We’ve now identified two really powerful imperatives for a C replacement: (1) solve the memory-management problem, and (2) minimize inward-transition costs from C. And the history – the praxeological context – of programming languages tells us that if a C successor candidate don’t address the transition-cost problem effectively enough, it almost doesn’t matter how good a job it does on anything else. Conversely, a C successor that _does_ address transition costs well buys itself a lot of slack for not being perfect in other ways.
|
||||
|
||||
This is what Go does. It’s not a theoretical jewel; it has annoying limitations; GC latency presently limits how far down the stack it can be pushed. But what it is doing is replicating the Unix/C infective strategy of being easy-entry and _good enough_ to propagate faster than alternatives that, if it didn’t exist, would look like better far bets.
|
||||
|
||||
Of course, the proboscid in the room when I say that is Rust. Which is, in fact, positioning itself as the better far bet. I’ve explained in previous installments why I don’t think it’s really ready to compete yet. The TIOBE and PYPL indices agree; it’s never made the TIOBE top 20 and on both indices does quite poorly against Go.
|
||||
|
||||
Where Rust will be in five years is a different question, of course. My advice to the Rust community, if they care, is to pay some serious attention to the transition-cost problem. My personal experience says the C to Rust energy barrier is _[nasty][2]_ . Code-lifting tools like Corrode won’t solve it if all they do is map C to unsafe Rust, and if there were an easy way to automate ownership/lifetime annotations they wouldn’t be needed at all – the compiler would just do that for you. I don’t know what a solution would look like, here, but I think they better find one.
|
||||
|
||||
I will finally note that Ken Thompson has a history of designs that look like minimal solutions to near problems but turn out to have an amazing quality of openness to the future, the capability to _be improved_ . Unix is like this, of course. It makes me very cautious about supposing that any of the obvious annoyances in Go that look like future-blockers to me (like, say, the lack of generics) actually are. Because for that to be true, I’d have to be smarter than Ken, which is not an easy thing to believe.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://esr.ibiblio.org/?p=7745
|
||||
|
||||
作者：[Eric Raymond ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
@ -0,0 +1,59 @@
|
||||
-最合理的语言工程模式
|
||||
-============================================================
|
||||
-
|
||||
-当你熟练掌握一体化工程技术时，你就会发现它逐渐超过了技术优化的层面。我们制作的每件手工艺品都在一个大环境背景下，在这个环境中，人类的行为逐渐突破了经济意义，社会学意义，达到了奥地利经济学家所称的“人类行为学”，这是目的明确的人类行为所能达到的最大范围。
|
||||
-
|
||||
-对我来说这并不只是抽象理论。当我在开源发展项目中编写时，我的行为就十分符合人类行为学的理论，这行为不是针对任何特定的软件技术或某个客观事物，它指的是在开发科技的过程中人类行为的背景环境。从人类行为学角度对科技进行的解读不断增加，大量的这种解读可以重塑科技框架，带来人类生产力和满足感的极大幅度增长，而这并不是由于我们换了工具，而是在于我们改变了掌握它们的方式。
|
||||
-
|
||||
-在这个背景下，我在第三篇额外的文章中谈到了 C 语言的衰退和正在到来的巨大改变，而我们也确实能够感受到系统编程的新时代的到来，在这个时刻，我决定把我之前有的大体的预感具象化为更加具体的，更实用的点子，它们主要是关于计算机语言设计的分析，例如为什么他们会成功，或为什么他们会失败。
|
||||
-
|
||||
-在我最近的一篇文章中，我写道：所有计算机语言都是对机器资源的成本和程序员工作成本的相对权衡的结果，和对其相对价值的体现。这些都是在一个计算能力成本不断下降但程序员工作成本不减反增的背景下产生的。我还强调了转化成本在使原有交易主张适用于当下环境中的新增角色。在文中我将编程人员描述为一个寻找今后最适方案的探索者。
|
||||
-
|
||||
-现在我要讲一讲最后一点。以现有水平为起点，一个语言工程师有极大可能通过多种方式推动语言设计的发展。通过什么系统呢？ GC 还是人工分配？使用何种配置，命令式语言，函数程式语言或是面向对象语言？但是从人类行为学的角度来说，我认为它的形式会更简洁，也许只是选择解决长期问题还是短期问题？
|
||||
-
|
||||
-所谓的“远”“近”之分，是指硬件成本的逐渐降低，软件复杂程度的上升和由现有语言向其他语言转化的成本的增加，根据它们的变化曲线所做出的判断。短期问题指编程人员眼下发现的问题，长期问题指可预见的一系列情况，但它们一段时间内不会到来。针对近期问题所做出的部署需要非常及时且有效，但随着情况的变化，短期解决方案有可能很快就不适用了。而长期的解决方案可能因其过于超前而夭折，或因其代价过高无法被接受。
|
||||
-
|
||||
-在计算机刚刚面世的时候， FORTRAN 是近期亟待解决的问题， LISP 是远期问题。汇编语言是短期解决方案，图解说明非通用语言的分类应用，还有关门电阻不断上涨的成本。随着计算机技术的发展，PHP 和 Javascript逐渐应用于游戏中。至于长期的解决方案？ Oberon , Ocaml , ML , XML-Docbook 都可以。 他们形成的激励机制带来了大量具有突破性和原创性的想法，事态蓬勃但未形成体系，那个时候距离专业语言的面世还很远，（值得注意的是这些想法的出现都是人类行为学中的因果，并非由于某种技术）。专业语言会失败，这是显而易见的，它的转入成本高昂，让大部分人望而却步，因此不能没能达到能够让主流群体接受的水平，被孤立，被搁置。这也是 LISP 不为人知的的过去，作为前 LISP 管理层人员，出于对它深深的爱，我为你们讲述了这段历史。
|
||||
-
|
||||
-如果短期解决方案出现故障，它的后果更加惨不忍睹，最好的结果是期待一个相对体面的失败，好转换到另一个设计方案。（通常在转化成本较高时）如果他们执意继续，通常造成众多方案相互之间藕断丝连，形成一个不断扩张的复合体，一直维持到不能运转下去，变成一堆摇摇欲坠的杂物。是的，我说的就是 C++ 语言，还有 Java 描述语言，（唉）还有 Perl，虽然 Larry Wall 的好品味成功地让他维持了很多年，问题一直没有爆发，但在 Perl 6 发行时，他的好品味最终引爆了整个问题。
|
||||
-
|
||||
-这种思考角度激励了编程人员向着两个不同的目的重新塑造语言设计: ①以远近为轴，在自身和预计的未来之间选取一个最适点，然后 ②降低由一种或多种语言转化为自身语言的转入成本，这样你就可以吸纳他们的用户群。接下来我会讲讲 C 语言是怎样占领全世界的。
|
||||
-
|
||||
-在整个计算机发展史中，没有谁能比 C 语言完美地把握最适点的选取了，我要做的只是证明这一点，作为一种实用的主流语言， C 语言有着更长的寿命，它目睹了无数个竞争者的兴衰，但它的地位仍旧不可取代。从淘汰它的第一个竞争者到现在已经过了 35 年，但看起来C语言的终结仍旧不会到来。
|
||||
-
|
||||
-当然，如果你愿意的话，可以把 C 语言的持久存在归功于人类的文化惰性，但那是对“文化惰性”这个词的曲解， C 语言一直得以延续的真正原因是没有人提供足够的转化费用！
|
||||
-
|
||||
-相反的， C 语言低廉的内部转化费用未得到应有的重视，C 语言是如此的千变万化，从它漫长统治时期的初期开始，它就可以适用于多种语言如 FORTRAN , Pascal , 汇编语言和 LISP 的编程习惯。在二十世纪八十年代我就注意到，我可以根据编程人员的编码风格判断出他的母语是什么，这也从另一方面证明了C 语言的魅力能够吸引全世界的人使用它。
|
||||
-
|
||||
-C++ 语言同样胜在它低廉的转化费用。很快，大部分新兴的语言为了降低自身转化费用，纷纷参考 C 语言语法。请注意这给未来的语言设计环境带来了什么影响：它尽可能地提高了 C-like 语言的价值，以此来降低其他语言转化为 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)
|
||||
-校对：[校对者ID](https://github.com/校对者ID)
|
||||
-
|
||||
-本文由 [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
|
||||
Loading…
Reference in New Issue
Block a user