我已有将近二十年的编程经验，并使用过各种编程语言进行开发。在我以前做过的很多工作和现在正在做的这份工作中，我非常高兴能够将 PHP 作为核心编程语言。从第一次使用 PHP 工作开始，我就听到了关于 PHP 的各种抱怨，但与此同时我也看到了 PHP 的威力。
本文最初发表于 PHPArch 网站 ，经原作者 Chris Tankersley 授权，InfoQ 中文站翻译并分享。
PHP 至少是一门有趣的编程语言。这门语言和用它构建的程序通常属于两种设计哲学。在这里，我所说的并非软件开发生命周期，如瀑布或灵敏，而是关于软件应该是什么样的基本头脑。这些头脑被称为“正确的方式”（The Right Way）和 “更糟就是更好”（Worse is better）。
PHP 又是一门相当希奇的编程语言。当人们抱怨这门语言“很槽糕”时，他们并没有说错。这门语言确实有很多不好的地方。搁在以前，这门语言还有更多糟糕的问题。嘲笑 PHP 的博文《全面解析 PHP 的槽糕设计》（PHP: a fractal of bad design）确实有几个正确的观点，即使这些观点在九年前发表时就已经过时了。
然而，与此同时，开发人员却可以使用 PHP 创建结构上“正确”的软件，并从其他语言中引入被视为良好实践的哲学。像 Laminas 和 Symfony 这样的框架就使用了面向对象编程的最佳实践，使开发者可以用这些框架编写结构正确的代码。
PHP 是怎么做到这些的？这是由于 PHP 是最糟糕的编程语言。
设计软件
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 好像是开发人员心中想要的编程语言。
1991 年，LISP 这么编程语言可能处于有史以来的最佳状态。这种技能上的正确性并没有被实际使用所证明。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 语言之上的一层脚本和函数设计的。
PHP 很简朴
设计肯定要简朴，不论是它的实现照旧接口。
PHP 底层使用了 C 语言，我们之前已经说过，这部门是“最糟糕的”。然而，这也带来了一些优势，最重要的是，更简朴的底层语言可以让它更容易扩展。虽然 Hack/HHVM 接纳了更多的 C++ 方法，但 PHP 本身仍旧是 C 语言。
只需短短几个小时就能学完这门语言的内部结构。Elizabeth Smith 发表过一篇关于 PHP 扩展的出色演讲，其中介绍了大量关于 PHP 的内部工作原理。这门语言本身借鉴了其他 C 风格的语言，不但易于阅读，而且能够跟 C 风格的其他语言互相转换。
PHP 的大多数接口，或者说标准库，都非常简朴，由于大多数核心功能都只不过是包装了各种 C 语言库，然后险些原封不动地公开出来。只管这样做会导致接口上的一些不一致，但是它为来自 C 或 C++ 的开发者提供了一个熟悉的环境。
PHP 语言非常注重于 Web 开发。将 HTTP 中的概念提取出来并在语言中找到相似的概念通常非常简朴。希望了解一个请求的头信息吗？get_headers() 就能满意你。获取请求信息就像读取 $_GET 和 $_POST 全局变量一样简朴。
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/ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
