任何讨论总是在一定的语境下进行的，违反讨论中的“语境”，或许是一切讨论错误的根源。
关于“语境”，可以参考这些观点：
1.Contrastivism 隐性语境，语境由被对比的事物构成。
2.Contextualism 显性语境，无需解释。
3.Subjective logic 如果我们相信思想必须根植于可靠的事实的话，就可以用Subjective logic表示“可靠程度”（当然，是在一定语境内的）

现在分析一个关于“简洁即力量”的讨论，从而探究“语境”。（关于“语境”的讨论需要大量的例子）
news ycombinator CΟΜ／item ? iδ=108861

“简洁即力量”是针对程序语言说的。
论证：
1.一个程序员，无论他写什么语言，一天写出的代码行数是差不多的。
2.程序语言越简洁，单位长度的功能越多。
3.因此，简洁即力量。
但有人就构造了这样一个反例：构造一种语言，叫Arc'。 Arc' 与 Arc 相同，除了 Arc' 有两种括号：{} 和 () 。
这两种括号没有语义上的差别，但程序员需要根据嵌套深度交替使用这两种括号，尽管这毫无道理，否则就是语法错误。

Oi, meddling with such definitions indeed puts us dangerously close to philosophy. As PG says in one of his essays, "the concepts we use in everyday life are fuzzy, and break down if pushed too hard". You're pushing too hard. It's a rule of thumb, not logical truth.
“pushing too hard”就是在打破语境。但是多大的攻击才可以叫做“pushing too hard”，仍然是一个问题。
If you insist on a logical truth, however, I think it's best to say that everything else being equal, a more succinct language is more powerful than a less succinct one.
加了“everything else being equal”，对是对了，但这个命题也就失去了意义（从来就不会有“除了一点以外都相同的编程语言”）。
I think if you tack on that qualification, then the statement becomes vacuous or at least near-so. Considerations in language design are dreadfully non-orthogonal to each other. I don't think you could measurably alter a language's succinctness without completely blowing away ceteris paribus.

Border cases are where the interesting things lie.
是不是因为语境的边缘能够产生新的语境？语境之间的穿梭是新语境的生长点，但是“保持讨论中的语境”却是最基本的原则。
语境，在讨论时应当遵守，但又需要打破。

A program written in Arc' has the same number of characters and tokens, but the specification of Arc' is slightly larger than that of Arc, so the languages themselves aren't quite equivalent. But, point taken. Power involves succinctness, simplicity, orthogonality and generality; Arc' certainly fails simplicity and orthogonality.
没法控制变量说个🔨，involve这么多东西，会造成无法比较，从而违反“前比较承诺”。
And, surely it wouldn't be too hard to write an editor mode to automatically toggle the braces and parens as needed, so with that enhancement writing Arc' would feel only slightly more awkward than writing Arc. The size of the language specification is what affects the ease of writing tools to manipulate it.

This is a nice thought experiment. We all know it proves nothing and at the same time, formally, it does prove something.
Let's get back to PG's original essay. What he says essentially is, if the goal of high-level languages is to make computer instructions (programs) shorter, then making them even shorter might be the ultimate goal of any high-level language. The shorter the better. Sounds like a very valid point.
However, there's something I think PG omits or disregards - the complexity of the language in terms of the total number of abstractions introduced, which intuitively should be low as well. In Lisp, which itself is a succinct language, you may have a framework with some number of functions in one case, and an equivalent framework with fewer functions in another case. Same applies to built-in constructs and notions - you may have fewer notions that cover same scenarios or vice versa, both producing (roughly) the same length in terms of tokens. But clearly, there's a difference and we'd prefer the framework that has fewer functions/abstractions/notions to remember.
So if we agree on this, Arc' is bad because it introduces more notions while achieving no or very little effect, if not harm actually.
竟然跳到了complexity上。一楼这种不合语境的“反例”，打破了旧语境。通过“complexity of the language in terms of the total number of abstractions introduced”，引入了新语境。

I think that the actual basis for "less code = more powerful" is psychological. You are less likely to want to write a feature if it requires putting up lots of boilerplate code. People tend to do what they want to do (discipline is highly overrated ;-)). So in a language that requires lots of boilerplate, you end up writing fewer features, even beyond the cost of typing (which is negligible for good typists).
Of course, there are other psychological factors at work. You are less likely to work on a project where you have to keep lots of unknowns in your head at once, and adjust them all simultaneously. (I suspect this is why Arc took 6 years to write.) You are not likely at all to work on a project where you can't understand the required language features, or can't figure out the existing code base. And it's no fun working on a project where every time you fix something, something else breaks.
The "ideal language", for me, would be the one that minimizes the sum of all these factors. IMHO, Java goes too far with the boilerplate, eliminating the gains it makes in not having to keep much of anything in your head. Arc makes for inscrutable code bases and requires that you keep the definitions of any macros you're using in your head. Complex JavaScript tends to break when you make small changes. Python hits the sweet spot for me, with liberal helpings of doctest and docstrings.
心理学都出来了！？

可以说，任何一个论断都能这么“攻击”一下，从而失去意义。

Stop trying to reduce the useful statement about succinctness being power into some logical rule or definition. Clearly its not a complete definition of language power, but contriving examples to break it doesn't prove an awful lot. I'm sure there exist any number of languages that are succinct but contain pathological clauses which make programming difficult.I'm pretty surprised that this community is having such a problem with language succinctness being an indicator of language power.
Interesting proof. I believe this does sufficiently prove BREVITY isn't the only consideration one must take while creating a language design. Fortunately, PG also considers other things as well, such as generality and flexibility. I agree incidentally, Arc' sounds like a terrible language. :PI believe the problem you may have with the "succinctness is power" philosophy PG uses is merely a matter of communication; the sad part about the English language (or any spoken language), is that it isn't perfect, and there is no way to exactly specify the full description of what he means by "power". Why? People learn most of their language in context, and depending on how that individual learned it and that persons professional and unprofessional background, there may be subtly different definitions of the way they use words. For example, a mathematician has a significantly different definition of the word "equal" than, say, the lady who works at the register of the local McDonald's.
This argument doesn't refute anything. All it demonstrates is that succinctness is not the only thing that enables a language to be powerful. I'm not sure anyone has ever made that claim.The fact that there are other things, such as sensible syntax, that can affect a language's power should come as a surprise to no-one.
总之，Arc' 论证是无效的。这个帖子后面在用Arc''无理取闹(打字会消耗血量的语言，打太长的程序就会死)。

所以，这个帖子只得到的下面的命题：
简洁不是决定力量的唯一因素。
然而这种东西只不过是个“常识”。讨论的目的在于产生新的思想，而不是去把“常识”清晰化。

猜想：语境是一种范式，而范式是规范的，因此语境是规范的，即可以表示为Axiology.
“语境是一种范式“显然。
“而范式是规范的”是其中猜想的部分，猜想的依据是因为都有“范”字。
（只属于中文的依据？用英语就不一样：Paradigms are normative.）
或许可以说得更直白一些：遵守讨论中的语境，是一种最基本的道德。
（这样说其实有问题，因为在某些体系里，“道德”是靠语境定义的）

从辩论到讨论，从真理到理性，从Reliable Facts到Feasible Facts，这是很大的转向。
可以有这样的情况：把Reliable Facts的标准定得非常高，导致什么话都不能说，一说就是错。这和一个根本不去思考的人没有任何区别。
早期的想法：RF的标准不能定得太高，否则就什么话都不能说；RF的标准又不能定得太低，否则所有的话都是论据，也无法得出结论。RF的标准应该恰好可以使得争执的双方中有一方胜出。
现在的想法：“高”和“低”都是相对于语境的。把RF的标准定得太极端显然不好，但并不是每个不走极端的RF标准都是合理的。有无数种方法使得争执的双方中有一方胜出，但是只有少数方法是符合语境的，它们还未必能产生新思想。这个标准无论如何都要Feasible.
为了避免上面的情况，需要这样的律法：
理性在世界中展开(unfold)自己。
这条律法还可以解决“缸中之脑”的悖论：无论是承认这个假设，还是否定它，都对理性在世上的展开没有好处。

关于“论证”
论证是一门学问。
但是若论证的内容无法在世界中展开的话，论证本身都是没有益处的。
比如“为什么很多人会特别执着于对错？”一文，从家庭关系和耻感文化上讨论这个问题。但是我们不可能改变这种文化，因此这个论证并没有用处。
还有大作家张斌的“吃肉使灵魂变小”，其实就是“素食主义者的理论基础”。我只想说，如果要做素食主义者，可以把“素食主义”作为根本价值，没有必要把“论证为真”作为根本价值，然后去论证什么“吃肉使灵魂变小”。
宗教之用最新的生物学证明神存在者，都不需要看，只需要回一句：“你究竟信神还是信生物？”