PHP 最少是两门有意思的C词汇。尖萼词汇和用它构筑的流程一般来说归属于三种内部结构设计神学。在这里，我所言的绝非应用软件设计开发周期，如峡谷或灵巧，而是关于应用软件应该是怎样的基本价值观。那些价值观被称为“恰当的形式”（The Right Way）和 “更为严重是更快”（Worse is better）。

PHP 又是两门十分怪异的C词汇。当人们埋怨尖萼词汇“很槽糕”时，他们并没有弄错。尖萼词汇的确有很多不太好的地方。

搁在从前，尖萼词汇还有更多差劲的问题。取笑 PHP 的昌明《全面性导出 PHP 的槽糕内部结构设计》（PHP: a fractal of bad design）的确有几个恰当的看法，即便那些看法在十二年前刊登时就已经落伍了。

不过，在此之后，开发人员却能利用 PHP 建立内部结构上“恰当”的应用软件，并从其他词汇中导入被视作较好课堂教学的神学。

像 Laminas 和 Symfony 这样的架构就使用了面向对象的最差课堂教学，使开发人员能用那些架构撰写内部结构恰当的标识符。

PHP 是怎么努力做到那些的？这原因在于 PHP 是最差劲的C词汇。

内部结构设计应用软件

1991 年，Richard P. Gabriel 刊登了一首诗《Lisp：坏消息，坏消息，如何获得大》（Lisp: Good News, Bad News, How to Win Big）。这首诗的论据是，在应用软件内部结构设计和使用寿命方面，“更为严重是更快”的神学将是更快的选择。

他或许得出结论这一推论，原因在于他意识到出现了三种不同的流程内部结构设计门派，他分别将之重新命名为“斯坦福大学 / 史丹福艺术风格”（MIT/Standford Style），或是“恰当的形式”，以及“波士顿艺术风格”（New Jersey Style）或是“更为严重是更快”。

这三种神学的最终目标相近，但在关键性应用领域却略有不同。三种艺术风格都着重于神学经营理念的五个关键性应用领域：单纯性（Simplicity）、恰当性（Correctness）、连续性（Consistency）和准确性（Completeness）。

斯坦福大学艺术风格是这样描述的：

至于波士顿艺术风格，Gabriel 说，它将其最终目标定义为：

这场争论的关键性是用 LISP 和 C 作为例子来说明为何“更为严重是更快”。对于 LISP 流程员 Gabriel 来说，LISP 是一种比 C 更快的词汇，速度和 C 一样快，而且 Common LISP 的内部结构设计、开发和标准化已经花了很多年。

定义该词汇的规范吸取了所有不同的 LISP 的精华，而现代开发环境对于 LISP 开发人员来说是最合适的。

LISP 是恰当的形式

LISP 代表了应用软件设计的“恰当的形式”。LISP 易于交互，你能通过各种形式与它交互。希望从 Fortran 中调用 LISP？

你能从 Fortran 中调用 LISP 并将数据传入，反之亦然。在使用遗留标识符时，你能愉快地使用 LISP 的所有现代“豪华”特性。

LISP 拥有一致的内部结构设计，这得益于它的规范。假如你研究一下 Python 这样的现代词汇，规范在提供多个后端和编译器方面有很大的作用，而且它们都以同样的形式解释或编译标识符。

那些工具是一流的，1991 年的 LISP 拥有我们今天仍然享受的所有舒适，比如步骤调试、数据检查和花哨的编辑器。

作为一种词汇，LISP 是完备的。它具有先进的面向对象层、多重继承、一流的对象以及函数和类型。LISP 似乎是开发人员心中想要的C词汇。

1991 年，LISP 这么C词汇可能处于有史以来的最差状态。这种技术上的恰当性并没有被实际使用所证实。

LISP 的开发商正在衰退。多年来负面新闻和错误定位阻碍了 LISP 的外部声誉。人们不再将其视为向最终用户交付应用软件的形式。

就开发而言，LISP 往往代表着许多与“大规模预先内部结构设计”（Big Design Up Front，BDUF）一样的理想。

假如你曾经使用过峡谷模型（Waterfall Model）这样的内部结构设计方法，你就会发现一些问题。“恰当的形式”非常强调连续性、恰当性，并确保考虑到所有能想到的问题。

LISP 本身绝非一种单一的词汇，而是一个词汇家族。尽管 Common LISP 被内部结构设计成一种标准，但是 LISP 本身的实现形式是根据需要完成的各种工作而存在的。

Lockless Inc 网站上的一首诗指出，这种“碎片化”是 LISP 最终失败的决定因素之一。尽管 LISP 坚持应用软件设计的“恰当的形式”，但是这种碎片化导致标识符维护和可移植性都受到了影响。

PHP 是最槽糕的

因此，“更为严重是更快”的应用软件首先会被接受，其次它会使用户期望更少，第三，那些应用软件将被不断改进，直到接近“恰当的方法”的程度。——Richard Gabrie

在这一启示的几年后，Rasmus Lerdorf 开始研究个人主页 / 表单解释器，也是我们现在所知的 PHP。

PHP/FI 的诞生原因在于 Lerdorf 需要维护他的主页，并与表单和数据库进行交互。PHP/FI 甚至不是作为一种实际的C词汇内部结构设计的，而是作为 C 词汇之上的一层脚本和函数内部结构设计的。

PHP 很单纯

内部结构设计一定要单纯，不论是它的实现还是接口。

PHP 底层使用了 C 词汇，我们之前已经说过，这部分是“最差劲的”。不过，这也带来了一些优势，最重要的是，更单纯的底层词汇能让它更容易扩展。虽然 Hack/HHVM 采用了更多的 C++ 方法，但 PHP 本身仍然是 C 词汇。

只需短短几个小时就能学完尖萼词汇的内部内部结构。Elizabeth Smith 刊登过一则关于 PHP 扩展的精彩演讲，其中介绍了大量关于 PHP 的内部工作原理。尖萼词汇本身借鉴了其他 C 艺术风格的词汇，不仅易于阅读，并且能够跟 C 艺术风格的其他词汇互相转换。

PHP 的大多数接口，或是说标准库，都非常单纯，因为大多数核心功能都只不过是包装了各种 C 词汇库，然后几乎原封不动地公开出来。尽管这样做会导致接口上的一些不一致，但是它为来自 C 或 C++ 的开发人员提供了一个熟悉的环境。

PHP 词汇非常注重于 Web 开发。将 HTTP 中的概念提取出来并在词汇中找到相近的概念

PHP 保持了单纯的开发人员接口，并且尽可能地保持内部内部结构的单纯。

PHP（几乎）是恰当的

在所有能观察到的方面，内部结构设计一定要恰当。但是能为了单纯性而轻微牺牲恰当性。

在这里，PHP 倾向于选择“单纯”而不是恰当。在 HHVM 出现之前，词汇的外观和特性一直没有得到规范。

Zend 解释器本身是规范，并且尖萼词汇的行为形式总是 “恰当”的（不包括实际的错误）。要想用别的东西代替 PHP 引擎，就必须实现现有引擎的所有特性。

许多核心函数的 LAX 函数参数和返回类型都使得系统的工作更容易。像 strpos() 这样的函数返回值能是整型数或布尔值，相对于严格内部结构设计成返回整型数或抛出异常的方法，处理要稍微容易一些。

看 PHP 词汇的发展，几乎所有新特性都是建立在开发人员需要的基础上，而不是“因为它错了所以必须修复”的严肃想法。

更多地关注那些严格类型和异常错误是一种更恰当的做事方法。不过，还有一些东西，比如简短的箭头函数（arrow function）、属性和枚举，才是开发人员想要用来简化标识符的东西。

PHP 不需要连续性

内部结构设计一定不能太过不一致。某些情况下，为了保持单纯能牺牲连续性。

我甚至不打算假装 PHP 是一致的，但是它的连续性已经足够了。当涉及到数组与字符串函数时，人们可能会埋怨 needle/haystack 参数顺序。

不过，一般而言，数组函数是一致的，而字符串函数也是一致的。与底层 C 库保持一致比在词汇中保持一致要单纯得多。

PHP 在其他方面也足够一致。正如我在 strpos() 中提到的，PHP 对于遇到错误的函数往往会十分一致地返回 FALSE。这未必是恰当的，但它却是一致的。带下划线和不带下划线的函数名一般来说都会匹配其基础库。

为了单纯起见， PHP 词汇牺牲了连续性，但是即便没有这个规范，它仍然努力在有意义的地方保持一致。

PHP 的准确性符合所需

内部结构设计一定要尽可能多地涵盖重要的情况。

无论何时，在针对 PHP 需求最大的内部结构设计任务：撰写 Web 应用流程时，PHP 都是完备的。PHP 从未被内部结构设计成一种能适用于编程世界所有问题的词汇。

尽管如此，它的单纯性还是使它能用于 Web 以外的场合。PHP 最初的目的是为 Web 编程提供最基本的功能，这一趋势一直持续至今。

修改核心词汇一般来说是由开发人员的需求驱动。整个社区提出修改意见，然后经由社区投票，决定新特性被拒绝、改变或是接受。该词汇的许多创新都源于快速完成工作的需要。

即便我们吸收了其它词汇的功能，也原因在于它使我们的开发变得单纯，而很少原因在于其他词汇做得“更恰当”。

今天，你能用 PHP 开发 Web 应用流程。五年后，你仍然能用 PHP 开发 Web 应用流程，只不过会增加一些新特性。

但是，词汇本身的准确性已经符合今天所需。如果未来有需要，我们能随时修改词汇或为它添加新功能。

更为严重是更快吗？

Gabriel 承认，“更为严重是更快”的神学指的是内部结构设计看起来很差劲，也许不应该作为更好的选择。唯一的问题是，当他审视这三种神学时，与斯坦福大学 /“恰当的形式”的内部结构设计神学相比，“更为严重是更快”最终仍然是更灵活的选择，“具有更快的生存特性”。如果我们看一下 PHP，就能证实“更为严重就是更快”这一看法。

那些年来，Gabriel 承认他在哪种形式更快之间摇摆不定。PHP 社区一直在争论我们是应该恰当地做事还是继续单纯地做事。

我们有像 Laminas 这样的架构，以经典的计算机科学形式构筑库，然后我们有像 Laravel 这样的架构，关注开发人员的体验和速度。PHP 本身二者兼具。

下次再听到有人骂 PHP 的时候，就随他喷去吧。尖萼词汇的确很差劲。但从许多方面来看，PHP 的长寿和广泛使用证明了这样一个事实：用“恰当的形式”做事并不总是比用“最差劲”的形式做事好。

当有人吐槽你正在使用的架构时，你要明白从长远来看这并不重要。选择一种你认为适合自己的内部结构设计神学，并欣然接受这一点：更为严重的可能实际上是更快。