PHP是另一种相当奇怪的编程语言。当人们抱怨语言“糟透了”时，他们并没有错。语言确实有很多不好的地方。撇开它不谈，这门语言还有很多更可怕的问题。博客文章《全面解析 PHP 的槽糕设计》（PHP：糟糕设计的分形）嘲笑PHP确实有一些有效的观点，即使它们在9年前发表时已经过时了。然而，与此同时，开发人员可以利用PHP来创建结构上“正确”的软件，并从其他语言中引入被认为是良好实践的理念。Laminas和Symfony等框架使用面向对象的编程最佳实践，允许开发人员使用这些框架编写结构良好的代码。PHP是如何做到这一点的？这是因为PHP是最糟糕的编程语言。设计软件1991年，RichardP.Gabriel发表了一篇文章《Lisp：好消息，坏消息，如何赢得大》(Lisp:GoodNews,BadNews,HowtoWinBig)。这篇文章的主题是，在软件设计和寿命方面，“越坏越好”的理念将是更好的选择。他得出这个结论是因为他意识到已经出现了两种不同的编程流派，他称之为“麻省理工/斯坦福风格”或“正确的方式”，以及“新泽西风格”或“越坏越好”。这两种理念有着相似的目标，但在关键领域有所不同。两种风格都侧重于哲学的四个关键领域：简单性、正确性、一致性和完整性。MIT风格描述如下：简单性：设计必须简单，无论是在实现上还是在界面上。保持界面简单更为重要。正确性：设计必须在所有可观察的方面都是正确的。不要试图做出错误的设计。一致性：设计不能不一致。为了确保一致性，您可以略微牺牲简单性和完整性。一致性和正确性同样重要。完整性：设计必须涵盖尽可能多的重要案例。必须涵盖所有预期的情况。完整性应优先于简单性。至于NewJersey风格，Gabriel说它将其目标定义为：简单：设计必须简单，无论是在实现还是在界面上。相反，保持实现简单更为重要。简单是最重要的，没有其他功能比保持简单更重要。正确性：设计必须在所有可观察的方面都是正确的。但是为了简单起见，可以稍微牺牲正确性。一致性：设计不能太不一致。在某些情况下，可以为了简单而牺牲一致性。如果在设计中引入不常见的情况会导致复杂或不一致的实现，那么就不要考虑它。完整性：设计必须涵盖尽可能多的重要案例。必须涵盖所有预期的情况。任何其他特性都可能损害完整性。事实上，只要实施的简单性受到威胁，就必须牺牲完整性。如果你想保持简单，你可以牺牲一致性来换取完整性；特别是接口的一致性。这场辩论的重点是使用LISP和C作为例子来说明为什么“越差越好”。对于LISP程序员Gabriel来说，LISP是一种比C更好的语言，和C一样快，而且CommonLISP花了很多年的时间来设计、开发和标准化。定义该语言的规范从所有不同的LISP中汲取了最好的东西，而现代开发环境对LISP开发人员来说是最好的。LISP是正确的方式LISP代表了软件开发的“正确方式”。LISP易于交互，您可以通过多种方式与它交互。想从Fortran调用LISP？您可以从Fortran调用LISP并传入数据，反之亦然。在处理遗留代码的同时，您可以愉快地使用LISP的所有现代“奢侈品”。由于其规范，LISP具有一致的设计。如果你看看像Python这样的现代语言，规范在提供多个后端和编译器方面做了很多工作，它们都以相同的方式解释或编译代码。这些工具是一流的，1991年的LISP拥有我们今天仍然享受的所有便利，比如逐步调试、数据检查和精美的编辑器。作为一种语言，LISP是完整的。它具有高级的面向对象编程层、多重继承、一流对象以及函数和类型。LISP似乎是开发人员心目中的编程语言。1991年，像LISP这样的编程语言可能处于有史以来最好的状态。这种技术上的正确性还没有被实际使用证明。LISP的开发者正在衰落。多年的负面报道和错误定位损害了LISP的外部声誉。人们不再将其视为向最终用户交付软件的一种方式。就开发而言，LISP倾向于代表许多与BigDesignUpFront(BDUF)相同的理想。如果您曾经使用过像瀑布模型这样的设计方法，您就会注意到一些问题。“正确的方法”非常强调一致性、正确性，并确保每个可以想到的问题都得到解决。LISP本身不是单一的语言，而是一个语言家族。尽管CommonLISP被设计为一个标准，但LISP本身的实现是基于需要完成的事情的种类而存在的。LocklessInc网站上的一篇文章指出，这种“碎片化”是LISP最终失败的决定性因素之一。尽管LISP坚持软件设计的“正确方式”，但这种碎片化导致代码维护和可移植性都受到影响。PHP是最差的，所以“worseisbetter”的软件首先会被接受，其次会让用户期望值降低，第三，这些软件会不断改进，直到接近“正道”。-RichardGabrie在这个启示几年后，RasmusLerdorf开始研究个人主页/表单解释器，我们现在称之为PHP。PHP/FI的诞生是因为Lerdorf需要维护他的主页并与表单和数据库进行交互。PHP/FI甚至没有被设计成一种实际的编程语言，而是被设计成在C之上的一层脚本和函数。PHP很简单设计必须简单，无论是它的实现还是接口。PHP在底层使用C语言，正如我们之前所说，这部分是“最糟糕的”。然而，这也带来了一些优势，最重要的是，更简单的底层语言可以使其更容易扩展。虽然Hack/HHVM采用更多的C++方法，但PHP本身仍然是C。只需几个小时即可了解该语言的内部结构。ElizabethSmith就PHP扩展发表了精彩的演讲，其中涵盖了很多关于PHP内部工作原理的内容。该语言本身借鉴了其他C风格语言。它不仅易于阅读，而且可以与其他C风格语言相互转换。PHP的大部分接口或标准库都非常简单，因为大多数核心功能无非就是包装各种C库并几乎不加改动地公开它们。虽然这样做会在接口中引入一些不一致，但它为来自C或C++的开发人员提供了一个熟悉的环境。PHP语言非常专注于Web开发。从HTTP中提取概念并在该语言中查找相似概念通常非常简单。想知道请求的标头吗？get_headers()会为你做这件事。获取请求信息就像读取_POST全局变量一样简单。PHP保持开发人员界面简单，并尽可能保持内部结构简单。PHP是（几乎）正确的在所有可观察的方面，设计必须是正确的。但是为了简单起见，可以稍微牺牲正确性。在这里，PHP倾向于选择“简单”而不是“正确”。直到HHVM出现之前，语言的外观和特性都没有标准化。Zend解释器本身就是规范，语言将始终以“正确”的方式运行（不包括实际错误）。要用其他东西替换PHP引擎，必须实现现有引擎的所有功能。许多核心函数的LAX函数参数和返回类型使使用系统更容易。像strpos()这样可以返回整数或布尔值的函数比严格设计用于返回整数或抛出异常的方法更容易处理。纵观PHP语言的发展历程，几乎所有的新特性都是建立在开发者需求的基础上，而不是“因为错了，就得改”的严肃思考。更多地关注那些严格的类型和异常错误是一种更正确的做事方式。但是，开发人员也希望使用短箭头函数、属性和枚举来简化代码。PHP不需要一致设计不能太不一致。在某些情况下，可以为了简单而牺牲一致性。我什至不会假装PHP是一致的，但它已经足够一致了。当涉及到数组函数与字符串函数时，人们可能会抱怨needle/haystack参数顺序。不过一般来说，数组函数是一致的，字符串函数也是一致的。与底层C库保持一致比跨语言保持一致要简单得多。PHP在其他方面也足够一致。正如我在strpos()中提到的，对于遇到错误的函数，PHP倾向于相当一致地返回FALSE。这不一定是真的，但它是一致的。带下划线和不带下划线的函数名通常会匹配它们的底层库。PHP语言为了简单而牺牲了一致性，但即使没有这个规范，它仍然努力在有意义的地方保持一致。PHP的完整性符合要求的设计，以涵盖尽可能多的重要案例。每当涉及到为PHP最苛刻的任务（编写Web应用程序）进行设计时，PHP就完成了。PHP从未被设计成一种可以适用于编程世界中所有问题的语言。尽管如此，它的简单性允许它在Web之外使用。PHP最初的目的是为Web编程提供最基本的功能，这种趋势一直持续到今天。修改核心语言通常是由开发人员的需求驱动的。整个社区提出修正案，然后社区投票决定是否拒绝、更改或接受新功能。该语言的许多创新源于快速完成任务的需要。即使当我们吸收其他语言的特性时，也是因为它使我们的开发更容易，很少是因为其他语言做得“更好”。现在，您可以使用PHP开发Web应用程序。五年后，您仍然可以使用PHP开发Web应用程序，只是具有一些新功能。但是，语言本身的完整性已经可以满足今天的需要。如果将来需要，我们可以随时修改语言或为其添加新功能。越差越好吗？Gabriel承认“越坏越好”的理念指的是看起来很糟糕并且可能不应该是更好选择的设计。唯一的问题是，当他审视这两种哲学时，与MIT/“正确的方式”设计哲学相比，“越坏越好”最终仍然是更灵活的选择，“具有更好的生存特性”。如果我们看一下PHP，“越坏越好”的论点得到证实。多年来，加布里埃尔承认他在哪个更好之间摇摆不定。PHP社区一直在争论我们是应该正确地做事还是继续简单地做事。我们有像Laminas这样的框架，以经典的计算机科学方式构建库，然后我们有像Laravel这样的框架，专注于开发人员的体验和速度。PHP本身就是两者。下次再听到有人骂PHP，就让他喷吧。语文真的很差。但在许多方面，PHP的长寿和广泛使用证明了以“正确的方式”做事并不总是比以“最差”的方式做事更好的事实。当有人抱怨你正在使用的框架时，要明白从长远来看这并不重要。选择一种您认为适合自己的设计理念，接受这样一个事实，即更糟的实际上可能更好。
