我已近整整三十年的程式设计实战经验，并采用过各式各样C词汇进行开发。在我从前做过的许多组织工作和现在正在做的这本组织工作中，我十分高兴能够将 PHP 作为核心理念C词汇。从第二次采用 PHP 组织工作开始，我就听见了关于 PHP 的各式各样埋怨，但在此之后我也看到了 PHP 的杀伤力。

责任编辑起初刊登于 PHPArch 中文网站 ，经原作 Chris Tankersley 许可，InfoQ 英文站译者并撷取。

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 坚持应用软件内部结构设计的“恰当的方式”，但是这种碎片化导致标识符维护和可移植性都受到了影响。

C 和 Unix 是错误的方式

同时，由于 Unix 的出现，C 词汇逐渐成为应用软件设计的首选方法。C 词汇是为 Unix 内部结构设计的，而 Unix 是用 C 词汇内部结构设计的。它的开发人员与斯坦福大学的 LISP 及其作者有着不同的内部结构设计立场。

在 1972 年，C 词汇被内部结构设计成一种简单的词汇。到 1991 年，它已经发生了一些变化，但是 C 词汇的基本原理没有改变。一些特性是为了满足开发人员和 Unix 的需求而添加的。因为词汇很简单，所以撰写编译器和流程很容易。尽管这种词汇并不会妨碍你进行复杂的程式设计，但是与 LISP 相比，C 词汇估计只有流程员所需的 50-80% 特性。

但是， C 词汇却有很强的可移植性。相对于常用于 LISP 应用软件和环境的硬件，它也能运行在低功率硬件上。这一因素使得它能在更广泛的机器上编译和运行应用软件。C 词汇和 Unix 很容易采用，Gabriel 认为 Unix 和 C 词汇会像病毒一样流行起来。

在 Dennis Ritchie 内部结构设计和构筑 Unix 的过程中，C 词汇得到了发展。因为贝尔实验室（Bell Labs）不被允许正式进入计算机领域，所以 Unix 也能轻松地分发给各式各样不同的用户。那些用户帮助修补 Unix 以满足他们自己的需求。Dennis Ritchie 能够根据需求将那些补丁整合在一起，而不必事先考虑那些需求。

与 LISP 不同，C 至今仍然被大量采用。尽管高级的解释性词汇，如 PHP、JavaScript 和 Python 是许多开发人员的首选，但是那些高级词汇许多都是用 C 词汇开发的。即使像 Rust 这样的竞争对手开始崭露头角，但能够在小型低功率设备上运行仍然是 C 词汇的优势。

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 的长寿和广泛采用证明了这样一个事实：用“恰当的方式”做事并不总是比用“最差劲”的方式做事好。当有人吐槽你正在采用的架构时，你要明白从长远来看这并不重要。选择一种你认为适合自己的内部结构设计哲学，并欣然接受这一点：更为严重的可能实际上更快。

作者介绍：

Chris Tankersley 拥有多种角色：丈夫、父亲、作家、演讲家、播客主持人和 PHP 开发人员。Chris 在 12 年的程式设计生涯中采用 了许多种不同的架构和词汇，但是他一天的大部分时间都在采用 PHP 和 Python。他是《Docker for Developers（尚无英文版）的作者，并与公司和开发人员合作，将容器整合到他们的组织工作流中。

原文链接：

https://www.phparch.com/2021/09/education-station-php-is-the-worst/