在我看来，绝大多数的打算机措辞，都存在“过度设计”的问题，也便是说，原来不该由措辞编译器操心的事，它们却费心费力的帮我们操心，替我们做主，而且还做的光明正大、理所应该似的。
下面就有请本日的三位被告登场，它们分别是：JAVA、PHP和C措辞。当然、它们只是被告团代表，这个天下上的数千种打算机措辞中相称大部分都存在着相似的问题。
首先让我们用三种措辞分写出相同逻辑的代码：
下面是三段代码
三段代码普通易懂，运行结果显而易见。但是先等一等，为什么这个结果是7呢？你大概会说当然是7了，不然还能是几？但我以为这个结果该当是9，而不应该是7，缘故原由很大略，1+2的结果是3，而33的结果是9。你肯定开始笑话我了，学过算数的人都知道乘号的优先级比加号的优先级要高，以是上边的1+23的运算该当先打算23，在进行加法运算1+6这样得到7。
但是请把稳你说的得到结果7的条件，是由于你知道优先级的观点，而你之以是知道是由于你学习过算数，但是打算机并没有上过小学，更没有学过算数，它凭什么要知道优先级的观点呢！
他又如何知道乘号要高于加号呢！
这便是我所说的“过度设计”。
打算机措辞的发明者对措辞进行了过度设计，在个中隐含了对数学运算符号优先级的定义。之以是这样做，目的是让打算机的运行结果符合我们的履历预期，符合我们的“潜规则”结果。
然而，我们的这套运算符优先级又是如何出身、为何要存在的呢？仔细想想你会意识到，这套优先级规则只会额外摧残浪费蹂躏大脑影象空间，并没有什么显著好处。
打算机虽然与数学关系紧密，但它该当具有自己的个性，在我看来一个精良的打算机措辞在设计之初就摒弃掉运算符号优先级的观点将所有符号优先级拉平，也便是说当你在研读某篇论文看到1+23这样的公式的时候，如果想将公式转换成打算机措辞，也要通过小括号补全“优先级”，如果你不写小括号，那么这门打算机措辞将不对符号优先级进行处理，而是依据从左往右的顺序进走运算，这样的好处大概是可以让措辞的设计者在写剖析器的时候少做不少事情，同时也在强制程序员明确定义运算顺序。这个运算顺序不应该让语法剖析器代劳，而是要由程序员明确指出。
好在这样的打算机措辞是存在的，例如Scheme便是这样的措辞。
如果用Scheme来写，大概要写成这样（+1（23））不要关心加号和乘号位置的缺点，实在这并不是缺点，它实在是叫做“前缀表达式”、也被称为“波兰式”便是将运算符号放在运算项的前面，如果我们用熟习的“中缀表达式”来写，它的形式便是我们熟习的样子，只不过对付Scheme措辞而言它只接管前缀表达式。我们更要把稳的是它愉快的括号，你会创造Scheme措辞中的括号是不能省略的。如果没有括号，它首先是报错，但假设没有括号对付Scheme是许可的，那么它很有可能从左往右进行打算，而不去考虑符号的优先级。当然这只是一个假设这样的措辞是前面我们提到的“很有自我个性的打算机措辞”，它要用“波兰式”来写表达式，它不接管你把括号省略这种
