Succinctness is Power

May 2002 "The quantity of meaning compressed into a small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid." - Charles Babbage, quoted in Iverson's Turing Award Lecture In the discussion about issues raised by Revenge of the Nerds on the LL1 mailing list, Paul Prescod wrote something that stuck in my mind.

2002 年 5 月 “代数符号将大量意义压缩到一个小空间中，这是另一种有助于我们习惯于在代数符号的帮助下进行推理的情况。” ——查尔斯·巴贝奇（Charles Babbage），艾弗森图灵奖演讲中引用的内容 在 LL1 邮件列表上关于《书呆子的复仇》提出的问题的讨论中，保罗·普雷斯科德 (Paul Prescod) 写了一些让我印象深刻的内容。

Python's goal is regularity and readability, not succinctness.

Python 的目标是规律性和可读性，而不是简洁性。

On the face of it, this seems a rather damning thing to claim about a programming language.

从表面上看，对于编程语言来说，这似乎是一个相当可恶的说法。

As far as I can tell, succinctness = power.

据我所知，简洁=力量。

If so, then substituting, we get Python's goal is regularity and readability, not power.

如果是这样，那么代入，我们就得到Python的目标是规律性和可读性，而不是功能。

and this doesn't seem a tradeoff (if it is a tradeoff) that you'd want to make.

这似乎不是您想要做出的权衡（如果它是权衡的话）。

It's not far from saying that Python's goal is not to be effective as a programming language.

毫不夸张地说，Python 的目标并不是成为一种有效的编程语言。

Does succinctness = power?

简洁=力量吗？

This seems to me an important question,

这对我来说似乎是一个重要的问题，

maybe the most important question for anyone interested in language design, and one that it would be useful to confront directly.

对于任何对语言设计感兴趣的人来说，这可能是最重要的问题，直接面对这个问题会很有用。

I don't feel sure yet that the answer is a simple yes, but it seems a good hypothesis to begin with.

我还不确定答案是否是简单的“是”，但这似乎是一个很好的假设。

Hypothesis My hypothesis is that succinctness is power, or is close enough that except in pathological examples you can treat them as identical.

假设 我的假设是简洁就是力量，或者足够接近，除了病态的例子之外，你可以将它们视为相同。

It seems to me that succinctness is what programming languages are

在我看来，简洁就是编程语言的本质

for.

为.

Computers would be just as happy to be told what to do directly in machine language.

计算机也会很高兴直接用机器语言告诉它该做什么。

I think that the main reason we take the trouble to develop high-level languages is to get leverage, so that we can say (and more importantly, think) in 10 lines of a high-level language what would require 1000 lines of machine language.

我认为我们不厌其烦地开发高级语言的主要原因是为了获得杠杆作用，这样我们就可以用 10 行高级语言说出（更重要的是，思考）需要 1000 行机器语言的内容。

In other words, the main point of high-level languages is to make source code smaller.

换句话说，高级语言的要点是使源代码更小。

If smaller source code is the purpose of high-level languages, and the power of something is how well it achieves its purpose, then the measure of the power of a programming language is how small it makes your programs.

如果更小的源代码是高级语言的目的，而某种东西的力量是它如何很好地实现其目的，那么衡量一种编程语言的力量就是它使你的程序有多小。

Conversely, a language that doesn't make your programs small is doing a bad job of what programming languages are supposed to do, like a knife that doesn't cut well, or printing that's illegible.

相反，如果一种语言不能让你的程序变小，那么它就没有很好地完成编程语言应该做的事情，就像一把刀不能很好地切割，或者打印难以辨认。

<!-- (There are niches for both of these, e.g. plastic knives made for children, or the way warning messages are printed on cigarette packages, but I think few languages want to be in such a niche.) --> Metrics Small in what sense though?

<!-- （这两者都有其利基市场，例如为儿童制造的塑料刀，或者在香烟包装上打印警告信息的方式，但我认为很少有语言愿意处于这样的利基市场。） --> 指标小在什么意义上呢？

The most common measure of code size is lines of code.

代码大小最常见的衡量标准是代码行数。

But I think that this metric is the most common because it is the easiest to measure.

但我认为这个指标是最常见的，因为它是最容易衡量的。

I don't think anyone really believes

我认为没有人真正相信

it is the true test of the length of a program.

这是对程序长度的真正考验。

Different languages have different conventions for how much you should put on a line; in C a lot of lines have nothing on them but a delimiter or two.

不同的语言对于一行中应该放置多少内容有不同的约定；在 C 语言中，很多行除了一两个分隔符之外什么都没有。

Another easy test is the number of characters in a program, but this is not very good either; some languages (Perl, for example) just use shorter identifiers than others.

另一个简单的测试是程序中的字符数，但这也不是很好；有些语言（例如 Perl）只是使用比其他语言更短的标识符。

I think a better measure of the size of a program would be the

我认为衡量程序规模的更好方法是

number of elements, where an element is anything that would be a distinct node if you drew a tree representing the source code.

元素的数量，如果您绘制代表源代码的树，则元素是可以成为不同节点的任何东西。

The name of a variable or function is an element; an integer or a floating-point number is an element; a segment of literal text is an element; an element of a pattern, or a format directive, is an element; a new block is an element.

变量或函数的名称是一个元素；整数或浮点数是一个元素；一段文字是一个元素；模式或格式指令的元素是元素；新块是一个元素。

There are borderline cases (is -5 two elements or one?) but I think most of them are the

存在边界情况（-5 是两个元素还是一个？），但我认为大多数都是

same for every language, so they don't affect comparisons much.

每种语言都相同，因此它们不会对比较产生太大影响。

This metric needs fleshing out, and it could require interpretation in the case of specific languages, but I think it tries to measure the right thing, which is the number of parts a program has.

这个指标需要充实，并且可能需要在特定语言的情况下进行解释，但我认为它试图衡量正确的东西，即程序具有的部分数量。

I think the tree you'd draw in this exercise is what you have to make in your head in order to conceive of the program, and so its size is proportionate to the

我认为你在这个练习中画的树就是你为了构思这个程序而必须在头脑中制作的树，所以它的大小与

amount of work you have to do to write or read it.

编写或阅读它需要做的工作量。

Design This kind of metric would allow us to compare different languages, but that is not, at least for me, its main value.

设计这种度量可以让我们比较不同的语言，但这不是，至少对我来说，它的主要价值。

The main value of the succinctness test is as a guide in designing languages.

简洁性测试的主要价值是作为设计语言的指南。

The most useful comparison between languages is between two potential variants of the same language.

语言之间最有用的比较是同一语言的两个潜在变体之间的比较。

What can I do in the language to make programs shorter?

我可以用该语言做什么来缩短程序？

If the conceptual load of a program is proportionate to its complexity, and a given programmer can tolerate a fixed conceptual load, then this is the same as asking, what can I do to enable programmers to get the most done?

如果程序的概念负载与其复杂性成正比，并且给定的程序员可以容忍固定的概念负载，那么这就相当于问，我可以做什么来使程序员能够完成最多的工作？

And that seems to me identical to asking, how can I design a good language?

在我看来，这就像问：我怎样才能设计出一种好的语言？

(Incidentally, nothing makes it more patently obvious that the old chestnut "all languages are equivalent" is false than designing

（顺便说一句，没有什么比设计更能明显地表明“所有语言都是等价的”这句老话是错误的了）

languages.

语言。

When you are designing a new language, you're constantly comparing two languages-- the language if I did x, and if I didn't-- to decide which is better.

当你设计一种新语言时，你会不断地比较两种语言——如果我做了x，如果我没有——来决定哪种更好。

If this were really a meaningless question, you might as well flip a coin.) Aiming for succinctness seems a good way to find new ideas.

如果这确实是一个毫无意义的问题，你不妨掷硬币。）力求简洁似乎是寻找新想法的好方法。

If you can do something that makes many different programs shorter, it is probably not a coincidence: you have

如果你可以做一些事情来使许多不同的程序变得更短，这可能不是巧合：你有

probably discovered a useful new abstraction.

可能发现了一个有用的新抽象。

You might even be able to write a program to help by searching source code for repeated patterns.

您甚至可以编写一个程序来通过搜索源代码中的重复模式来提供帮助。

Among other languages, those with a reputation for succinctness would be the ones to look to for new ideas: Forth, Joy, Icon.

在其他语言中，那些以简洁着称的语言将是寻找新想法的语言：Forth、Joy、Icon。

Comparison The first person to write about these issues, as far as I know, was Fred Brooks in the Mythical Man Month .

比较 据我所知，第一个写到这些问题的人是《人月神话》中的 Fred Brooks。

He wrote that programmers seemed to generate about the same

他写道，程序员似乎生成了大约相同的结果

amount of code per day regardless of the language.

无论语言如何，每天的代码量。

When I first read this in my early twenties, it was a big surprise to me and seemed to have huge implications.

当我二十岁出头时第一次读到这篇文章时，我感到非常惊讶，并且似乎具有巨大的含义。

It meant that (a) the only way to get software written faster was to use a more succinct language, and (b) someone who took the trouble to do this could leave competitors who didn't in the dust.

这意味着（a）加快软件编写速度的唯一方法是使用更简洁的语言，（b）不辞辛劳这样做的人可能会将那些不这样做的竞争对手远远甩在身后。

Brooks' hypothesis, if it's true, seems to be at the very heart of hacking.

布鲁克斯的假设如果正确的话，似乎就是黑客攻击的核心。

In the years since, I've paid close attention to any evidence I could get on the question, from formal studies to anecdotes about individual projects.

从那以后的几年里，我一直密切关注我能得到的关于这个问题的任何证据，从正式的研究到有关单个项目的轶事。

I have seen nothing to contradict him.

我没有看到任何可以反驳他的内容。

I have not yet seen evidence that seemed to me conclusive, and I don't expect to.

我还没有看到在我看来确凿的证据，而且我也不指望会看到。

Studies like Lutz Prechelt's comparison of programming languages, while generating the kind of results I expected, tend to use problems that

像 Lutz Prechelt 的编程语言比较这样的研究，虽然产生了我所期望的结果，但往往使用以下问题：

are too short to be meaningful tests.

太短而无法成为有意义的测试。

A better test of a language is what happens in programs that take a month to write.

对语言的更好测试是花费一个月编写的程序中发生的情况。

And the only real test, if you believe as I do that the main purpose of a language is to be good to think in (rather than just to tell a computer what to do once you've thought of it) is what new things you can write in it.

如果你像我一样相信语言的主要目的是善于思考（而不是仅仅告诉计算机一旦你想到它该怎么做），那么唯一真正的测试就是你可以用它写出什么新东西。

So any language comparison where you have to meet a predefined spec is testing slightly the wrong

因此，任何必须满足预定义规范的语言比较都是测试稍微错误的

thing.

事。

The true test of a language is how well you can discover and solve new problems, not how well you can use it to solve a problem someone else has already formulated.

对一门语言的真正考验是你能多好地发现和解决新问题，而不是你能多好地用它来解决别人已经提出的问题。

These two are quite different criteria.

这两个是完全不同的标准。

In art, mediums like embroidery and mosaic work well if you know beforehand what you want to make, but are absolutely lousy if you don't.

在艺术中​​，如果你事先知道你想做什么，像刺绣和马赛克这样的媒介就可以很好地发挥作用，但如果你不知道，那就绝对糟糕了。

When you want to discover the image as you make it--

当你想在制作图像时发现它——

as you have to do with anything as complex as an image of a person, for example-- you need to use a more fluid medium like pencil or ink wash or oil paint.

例如，因为您必须处理像人物图像这样复杂的事物，所以您需要使用更流畅的介质，例如铅笔、水墨或油画。

And indeed, the way tapestries and mosaics are made in practice is to make a painting first, then copy it.

事实上，挂毯和马赛克的实际制作方式是先画一幅画，然后临摹它。

(The word "cartoon" was originally used to describe a painting intended for this purpose).

（“卡通”一词最初用于描述用于此目的的绘画）。

What this means is that we are never likely to have accurate comparisons

这意味着我们永远不可能进行准确的比较

of the relative power of programming languages.

编程语言的相对力量。

We'll have precise comparisons, but not accurate ones.

我们会进行精确的比较，但不是准确的比较。

In particular, explicit studies for the purpose of comparing languages, because they will probably use small problems, and will necessarily use predefined problems, will tend to underestimate the power of the more powerful languages.

特别是，以比较语言为目的的显式研究，因为它们可能会使用小问题，并且必然会使用预定义的问题，因此往往会低估更强大语言的威力。

Reports from the field, though they will necessarily be less precise than

来自现场的报告，尽管它们必然不如

"scientific" studies, are likely to be more meaningful.

“科学”的研究可能更有意义。

For example, Ulf Wiger of Ericsson did a study that concluded that Erlang was 4-10x more succinct than C++, and proportionately faster to develop software in: Comparisons between Ericsson-internal development projects indicate similar line/hour productivity, including all phases of software development, rather independently of which language (Erlang, PLEX, C, C++, or Java)

例如，爱立信的 Ulf Wiger 进行了一项研究，得出的结论是 Erlang 比 C++ 简洁 4-10 倍，并且在以下方面开发软件的速度相应更快： 爱立信内部开发项目之间的比较表明，生产线/小时生产率相似，包括软件开发的所有阶段，而与哪种语言（Erlang、PLEX、C、C++ 或 Java）无关

was used.

被使用了。

What differentiates the different languages then becomes source code volume.

不同语言的区别就变成了源代码量。

The study also deals explictly with a point that was only implicit in Brooks' book (since he measured lines of debugged code): programs written in more powerful languages tend to have fewer bugs.

这项研究还明确涉及了布鲁克斯书中隐含的一个观点（因为他测量了调试代码行）：用更强大的语言编写的程序往往有更少的错误。

That becomes an end in itself, possibly more important than programmer productivity, in applications like network switches.

在网络交换机等应用中，这本身就是一个目的，可能比程序员的生产力更重要。

The Taste Test Ultimately, I think you have to go with your gut.

味觉测试 最终，我认为你必须跟随你的直觉。

What does it feel like to program in the language?

用该语言编程感觉如何？

I think the way to find (or design) the best language is to become hypersensitive to how well a language lets you think, then choose/design the language that feels best.

我认为找到（或设计）最好的语言的方法是对一种语言让你思考的能力变得高度敏感，然后选择/设计感觉最好的语言。

If some language feature is awkward or restricting, don't worry, you'll know about it.

如果某些语言功能令人尴尬或受到限制，请不要担心，您会知道的。

Such hypersensitivity will come at a cost.

这种过度敏感是要付出代价的。

You'll find that you can't

你会发现你做不到

stand programming in clumsy languages.

忍受用笨拙的语言编程。

I find it unbearably restrictive to program in languages without macros, just as someone used to dynamic typing finds it unbearably restrictive to have to go back to programming in a language where you have to declare the type of every variable, and can't make a list of objects of different types.

我发现用没有宏的语言进行编程受到了难以忍受的限制，就像习惯动态类型的人发现必须回到必须声明每个变量的类型并且无法列出不同类型的对象列表的语言进行编程一样受到难以忍受的限制。

<!-- (It's like one of those nightmares where you have to go back to

<!--（这就像那些你必须回到的噩梦之一

high school.) --> I'm not the only one.

高中。） --> 我不是唯一一个这样的人。

I know many Lisp hackers that this has happened to.

我知道很多 Lisp 黑客都遇到过这种情况。

In fact, the most accurate measure of the relative power of programming languages might be the percentage of people who know the language who will take any job where they get to use that language, regardless of the application domain.

事实上，衡量编程语言相对能力的最准确的衡量标准可能是了解该语言的人中愿意接受使用该语言的任何工作的人的百分比，无论应用程序领域如何。

Restrictiveness I think most hackers know what it means for a language to feel restrictive.

限制性 我认为大多数黑客都知道一种语言的限制性意味着什么。

What's happening when you feel that?

当你有这种感觉时，发生了什么？

I think it's the same feeling you get when the street you want to take is blocked off, and you have to take a long detour to get where you wanted to go.

我想这和你想去的那条路被封锁了，你必须绕很远的路才能到达你想去的地方时的感觉是一样的。

There is something you want to say, and the language won't let you.

有些话你想说，但语言不允许你说。

What's really going on here, I think, is that a restrictive language is one that isn't succinct enough.

我认为，这里真正发生的事情是限制性语言不够简洁。

The problem is not simply that you can't

问题不仅仅是你不能

say what you planned to.

说出你的计划。

It's that the detour the language makes you take is longer.

而是语言让你走的弯路更长。

Try this thought experiment.

尝试这个思想实验。

Suppose there were some program you wanted to write, and the language wouldn't let you express it the way you planned to, but instead forced you to write the program in some other way that was shorter.

假设您想编写一些程序，而该语言不允许您按照您计划的方式表达它，而是强迫您以其他更短的方式编写该程序。

For me at least, that wouldn't feel very restrictive.

至少对我来说，这不会感觉很受限制。

It would be like the street you

这就像你的街道

wanted to take being blocked off, and the policeman at the intersection directing you to a shortcut instead of a detour.

想要被封锁，路口的警察指引你走捷径而不是绕路。

Great!

伟大的！

I think most (ninety percent?) of the feeling of restrictiveness comes from being forced to make the program you write in the language longer than one you have in your head.

我认为大部分（百分之九十？）的限制感来自于被迫让你用该语言编写的程序比你脑子里的程序长。

Restrictiveness is mostly lack of succinctness.

限制性主要是缺乏简洁性。

So when a language feels restrictive, what that (mostly) means is that it isn't

因此，当一种语言感觉受到限制时，（主要）意味着它不是

succinct enough, and when a language isn't succinct, it will feel restrictive.

足够简洁，当一种语言不够简洁时，就会给人一种限制性的感觉。

Readability The quote I began with mentions two other qualities, regularity and readability.

可读性 我开头引用的这句话提到了另外两个品质：规律性和可读性。

I'm not sure what regularity is, or what advantage, if any, code that is regular and readable has over code that is merely readable.

我不确定什么是规律性，或者规律性和可读性的代码相对于仅仅可读性的代码有什么优势（如果有的话）。

But I think I know what is meant by readability, and I think it is also related to succinctness.

但我想我知道可读性是什么意思，我认为这也与简洁有关。

We have to be careful here to distinguish between the readability of an individual line of code and the readability of the whole program.

这里我们必须小心区分单行代码的可读性和整个程序的可读性。

It's the second that matters.

重要的是第二个。

I agree that a line of Basic is likely to be more readable than a line of Lisp.

我同意一行 Basic 可能比一行 Lisp 更具可读性。

But a program written in Basic is is going to have more lines than the same program written in Lisp (especially once you cross over into Greenspunland).

但是用 Basic 编写的程序将比用 Lisp 编写的相同程序有更多的行数（尤其是当你跨入 Greenspunland 时）。

The

的

total effort of reading the Basic program will surely be greater.

阅读Basic程序的总努力肯定会更大。

total effort = effort per line x number of lines I'm not as sure that readability is directly proportionate to succinctness as I am that power is, but certainly succinctness is a factor (in the mathematical sense; see equation above) in readability.

总工作量 = 每行工作量 x 行数 我不太确定可读性与简洁性成正比，但我确信简洁性是可读性的一个因素（在数学意义上；参见上面的等式）。

So it may not even be meaningful to say that the goal of a language is readability, not succinctness; it could be like saying the goal was readability,

因此，说一种语言的目标是可读性而不是简洁性可能没有任何意义。这可能就像说目标是可读性，

not readability.

不可读。

What readability-per-line does mean, to the user encountering the language for the first time, is that source code will look unthreatening .

对于第一次接触该语言的用户来说，每行可读性意味着源代码看起来没有威胁性。

So readability-per-line could be a good marketing decision, even if it is a bad design decision.

因此，每行可读性可能是一个很好的营销决策，即使它是一个糟糕的设计决策。

It's isomorphic to the very successful technique of letting people pay in installments: instead of frightening them with a high upfront price, you tell them the low monthly payment.

它与让人们分期付款的非常成功的技术同构：不要用高额预付款来吓唬他们，而是告诉他们每月付款较低。

Installment plans

分期付款计划

are a net lose for the buyer, though, as mere readability-per-line probably is for the programmer.

然而，对于买家来说却是一个净损失，因为对于程序员来说，仅仅每行的可读性可能就是一个损失。

The buyer is going to make a lot of those low, low payments; and the programmer is going to read a lot of those individually readable lines.

买家将支付大量的低额付款；程序员将读取大量单独可读的行。

This tradeoff predates programming languages.

这种权衡早于编程语言。

If you're used to reading novels and newspaper articles, your first experience of reading a math paper can be dismaying.

如果您习惯阅读小说和报纸文章，那么您第一次阅读数学论文的经历可能会令人沮丧。

It could take half an hour to read a single page.

读一页可能需要半个小时。

And yet, I am pretty sure that the notation is not the problem, even though it may feel like it is.

然而，我很确定符号不是问题，尽管感觉上可能是问题。

The math paper is hard to read because the ideas are hard.

数学论文很难读，因为其中的想法很难。

If you expressed the same ideas in prose (as mathematicians had to do before they evolved succinct notations), they wouldn't be any easier to read, because the paper would grow to the size of a book.

如果你用散文表达同样的想法（数学家在发展出简洁的符号之前必须这样做），它们不会更容易阅读，因为论文会增长到一本书的大小。

To What Extent?

到什么程度？

A number of people have rejected

不少人都拒绝了

the idea that succinctness = power.

简洁=力量的理念。

I think it would be more useful, instead of simply arguing that they are the same or aren't, to ask: to what extent does succinctness = power?

我认为，与其简单地争论它们相同或不同，不如问：简洁性=力量到什么程度会更有用？

Because clearly succinctness is a large part of what higher-level languages are for.

因为显然简洁是高级语言的一个重要部分。

If it is not all they're for, then what else are they for, and how important, relatively, are these other functions?

如果这不是它们的全部用途，那么它们还有什么用途，以及这些其他功能相对而言有多重要？

I'm not proposing this just to make the debate more civilized.

我提出这一点并不是为了让辩论更加文明。

I really

我真的

want to know the answer.

想知道答案。

When, if ever, is a language too succinct for its own good?

如果有的话，什么时候一种语言会变得过于简洁而不利于其自身？

The hypothesis I began with was that, except in pathological examples, I thought succinctness could be considered identical with power.

我一开始的假设是，除了病态的例子之外，我认为简洁可以被认为与力量相同。

What I meant was that in any language anyone would design, they would be identical, but that if someone wanted to design a language explicitly to disprove this hypothesis, they could probably do it.

我的意思是，在任何人设计的任何语言中，它们都是相同的，但如果有人想明确设计一种语言来反驳这个假设，他们可能可以做到。

I'm

我是

not even sure of that, actually.

实际上，甚至不确定。

Languages, not Programs We should be clear that we are talking about the succinctness of languages, not of individual programs.

语言，而不是程序 我们应该清楚，我们正在谈论语言的简洁性，而不是单个程序的简洁性。

It certainly is possible for individual programs to be written too densely.

个别程序当然有可能写得过于密集。

I wrote about this in On Lisp .

我在《On Lisp》中写到了这一点。

A complex macro may have to save many times its own length to be justified.

复杂的宏可能必须保存其自身长度的许多倍才能证明其合理性。

If writing some hairy macro could save you ten lines of code every time you use it,

如果编写一些毛茸茸的宏可以让你每次使用它时节省十行代码，

and the macro is itself ten lines of code, then you get a net saving in lines if you use it more than once.

并且宏本身有十行代码，如果您多次使用它，您将获得净节省的行数。

But that could still be a bad move, because macro definitions are harder to read than ordinary code.

但这仍然可能是一个糟糕的举动，因为宏定义比普通代码更难阅读。

You might have to use the macro ten or twenty times before it yielded a net improvement in readability.

您可能需要使用宏十次或二十次才能产生可​​读性的净改进。

I'm sure every language has such tradeoffs (though I suspect the stakes get higher as the language gets more powerful).

我确信每种语言都有这样的权衡（尽管我怀疑随着语言变得更强大，风险也会更高）。

Every programmer must

每个程序员都必须

have seen code that some clever person has made marginally shorter by using dubious programming tricks.

我见过一些聪明人通过使用可疑的编程技巧而使代码变得稍微短一些。

So there is no argument about that-- at least, not from me.

所以对此没有任何争论——至少我没有。

Individual programs can certainly be too succinct for their own good.

个别计划当然可能过于简洁，不利于其自身利益。

The question is, can a language be?

问题是，语言可以吗？

Can a language compel programmers to write code that's short (in elements) at the expense of overall readability?

一种语言是否可以迫使程序员以牺牲整体可读性为代价来编写简短的代码（元素）？

One reason it's hard to imagine a language being too succinct is that if

很难想象一种语言过于简洁的原因之一是，如果

there were some excessively compact way to phrase something, there would probably also be a longer way.

有一些过于紧凑的方式来表达某件事，也可能会有更长的方式。

For example, if you felt Lisp programs using a lot of macros or higher-order functions were too dense, you could, if you preferred, write code that was isomorphic to Pascal.

例如，如果您觉得使用大量宏或高阶函数的 Lisp 程序过于密集，如果您愿意，您可以编写与 Pascal 同构的代码。

If you don't want to express factorial in Arc as a call to a higher-order function (rec zero 1 * 1-)

如果您不想在 Arc 中将阶乘表示为对高阶函数的调用 (rec 0 1 * 1-)