php php文件用什么软件打开 收藏 0

PHP 没你想的那么差

PHP现在名声很糟糕，因为它曾经是“可怕”的。本文试着回答一些常见的关于 PHP 的断言，目的是向非技术人员解释，PHP 并不像许多人所说的那么糟糕。

不再是了。过去，许多开发者被书本教授非常糟糕的实践，因此 PHP 代码的质量非常差。PHP 曾经还允许你做一些非常奇怪的事情，使得它非常容易构建，但维护起来却是一场噩梦。

这些不再是常见的问题。随着高质量学习材料的引入，这些材料易学且易获取，一名新的开发人员可以以正确的方式学习 PHP。这样就可以避免初级开发者因为不知道构建事物的正确方法而编写一些维护起来非常痛苦的代码。

随着框架的引入，导致许多糟糕体验的大部分通用代码现在都自动完成了；因此，开发人员只需使用框架，框架就可以正确地对其进行编码。

而且，这些年来，一些糟糕的实践是由缺失的特性造成的，导致了一些本不应该被允许的事情被允许。现在大多数情况下，甚至不可能实现以前编写的一些东西来导致这种声誉。

• 它不再鼓励糟糕的实践…
• 通过使用框架避免了糟糕实践。
• 语言特性现在有很多讨论。糟糕的特性不再受到支持。
• PHP 添加了其他语言中存在的大部分（即使不是全部）的特性。

过去，PHP应用程序的安全性通常很差，因为语言允许这样做。这些东西不再被使用，因为 PHP 应用程序的开发现在已经完全不同。

通过使用自动加载程序来包含文件而不是动态包含文件，已经移除了远程和本地文件包含（其中 PHP 从其它地址而不是最初打算的地址读取文件）。

通过广泛使用模板系统（可以自动处理显示动态内容的转义和安全问题），已经避免了由于直接在 PHP 中直接使用 HTML 所导致的跨站脚本攻击（其中一个用户将 JavaScript 脚本添加到要显示给另一个用户的地方）。

通过在 SQL 中使用 prepared 语句，避免了 SQL 注入攻击（这是由于需要构建 SQL 查询并将查询和数据一起发送导致的，其中用户可以向查询中增加额外的 SQL 命令）。另外，ORM 的使用也很普遍，它确保用户数据和查询是分开发送的，而 SQL 不能将其视为单独的命令。

通过广泛使用且采用 nonce 系统的 form 库，避免了跨站请求伪造（其中，用户能够被诱骗在你的站点上执行某些操作）。

• 不再是了。
• 通过使用自动加载程序（所有主流框架的标配），避免了远程和本地文件包含。
• 通过使用模板语言作为标准或一种前端框架（例如 React），避免了跨站脚本（XSS）攻击。
• 通过使用 ORMs 和广泛使用 prepared 语句，避免了 SQL 注入。
• 通过使用 nonce token（被所有主流框架自动支持），避免了跨站请求伪造（CRSF）攻击。

这取决于你把它与什么比较。如果你把 PHP 与 Java、C 或者 Go 比较，那么它是比较慢。但是如果你把 PHP 与 Python、Ruby 等等比较，那么它并不慢。在同类型的语言中，PHP 是最快的之一，并且不断在提高性能。

大多数情况下，你的应用程序慢是因为服务器过载或者数据库查询慢。这些问题在任何语言中都会存在。

• PHP 与编译型语言相比是比较慢。
• PHP 与其它脚本型语言相比是比较快的。
• 网站慢通常不是由于使用的语言不够快，而是因为服务器或数据库导致的性能问题。

实际上，任何语言都可以伸缩。编译型语言（例如 Go、C 或 Rust）比脚本型语言（例如 PHP）的扩展成本更低。然而，它们并不是为了同样的任务而设计的。事实上，它们都是一样的；这简单地归结于你使用的服务器数量。如果你使用足够多的服务器，你可以扩展任何应用程序。PHP 比其它脚本型语言的扩展成本更低，因为它需要更少的资源来开始运行，并且可以在具有更多 CPU 的较小内存的服务器上运行。

另外，对于伸缩性，重要的是数据库。如果你能够扩展你的数据库，你就可以扩展你的应用程序。数据库比应用服务器更难扩展。增加另一个读取数据库的客户端很容易；但是，让数据库快速运行要难得多。

• 任何语言都可以伸缩；这取决于你使用多少服务器。
• 扩展的真正问题是数据库而不是所使用的应用程序语言。
• 如果你能够扩展你的数据，你就能扩展你的应用程序。

不。每种编程语言都有其擅长的领域。PHP 非常适合 Web 应用程序。你应该用它来构建网站和 API。

如果你正在构建一个系统应用程序，其中每毫秒都很重要，使用 Rust 或者 C。

如果你正在构建一个人工智能应用程序，Python 是一个好选项。

如果你正在构建一个 SaaS 应用程序，PHP 是一个好选项。

如果你正在构建一个安卓应用程序，Kotlin 是一个好选项。

如果你正在构建一个运行在多个平台上的应用程序，Java 是一个好选项。

• 不，每种语言都有其最佳用例。
• PHP 的最佳用例是 Web 应用程序。
• Go、Rust、C 适合系统应用程序。
• Python 适合人工智能。
• Kotlin 适合安卓应用程序。
• Java 适合与平台无关的应用程序。

很多关于 PHP 的说法都已经过时 10 年了。在我们看来，如果有人给你关于某个技术主题的过期 10 年的信息，那么这个人可能不是你想要信任的技术专家。

PHP 是创建 Web 应用程序的一门好编程语言，我们认为它是 Web 应用程序开发的最佳语言。

• 这些抱怨中很多都过期 10 年了。
• 我们认为 PHP 是构建 Web 应用程序的最佳语言。

原文链接：

https://www.getparthenon.com/blog/php-isnt-that-like-really-bad/

短短两年使用率下滑 40%！曾经风靡全球的 PHP 为何逐渐失去优势？

作者 | Richard MacManus

译者 | 核子可乐

策划 | Tina

根据 WordPress 联合创始人 Matt Mullenweg 的说法，PHP 的受众比例急剧下降，疑似受到 WordPress“JavaScript 优先”主张的影响。

TIOBE 编程语言人气指数发布更新，并提出“PHP 的魔力是否正在消散？”的灵魂拷问。今年 4 月，PHP 在 TIOBE 编程语言指数榜上仅位列第 17，“成为其有史以来的最低排位”。

暴露 PHP 人气急剧下滑的还不只是 TIOBE 榜单。在年度 Stack Overflow 开发者调查报告中，PHP 的市场占比也从 2018 年的 30.7%（即受访者当中使用 PHP 的百分比）下降至 2023 年的 18.58%。JetBrains 开发者生态系统调查同样观察到类似的趋势，PHP 占比从 2017 年的 30%下降至 2023 年的 18%。而且最后一项数据尤其值得关注，因为 JetBrains（以及 WordPress 托管厂商 Automattic）正是 PHP 的最大赞助方之一。

JetBrains 公布的开发者调查结果

这种下滑趋势在 BuiltWith 上体现得尤其明显，自 2020 年底以来 PHP 的流行度增长线开始断崖式跌落。

BuiltWith 公布的 PHP 趋势图

截至 2021 年 11 月的一项调查显示，PHP 在互联网前百万个网站中的占比仍在 3 万以上。但如今两年多过去，其占比已经下滑至 1.5 万左右。而且截至本文撰稿之时，BuiltWith Quotes 公布的实际占比数字为 18.19%。18%这个比例与 Stack Overflow 及 JetBrains 的调查发现高度吻合，因此我们可以基本确定，PHP 在开发者中的受欢迎程度已经从之前的约 30%萎缩至现在的 18%。换言之，在短短两年之间下降了 40%。

所以结论是什么？在过去几年里到底发生了什么样的变化，才导致 PHP 在 Web 编程语言的竞争当中迅速落败？

可以说，PHP 衰落的最大原因就是 WordPress（迄今为止最具人气的 Web 内容管理系统）正在从 PHP 转向 JavaScript。WordPress 联合创始人兼 Automattic 公司 CEO Matt Mullenweg 在上月于中国台湾召开的 WordCamp Asia 2024 大会上也就此做出论述。

他在回答观众提问时表示，“我觉得 WordPress 中的大部分新代码现在都是由 JavaScript 编写而成，而且这种趋势已经持续了一段时间。因此从方方面面来讲，如今的 Gutenberg 已经转化成了一个 JavaScript 优先的项目。”

大家绝没看错：Matt Mullenweg 直言现在的 WordPress 就是个“JavaScript 优先的项目”。而他所提到的 Gutenberg，其实是该公司备受争议的全新用户界面，同时也是推动 JavaScript 全面替代 PHP 的主要原因。当然，他也承认从 PHP 转向 JavaScript“并不容易”。

WordPress 联合创始人 Matt Mullenweg 在 WordCamp Asia 2024 大会上

这倒不是说 WordPress 不再依赖于 PHP。毕竟在撰写本文时，我恰好就是在 WordPress 中以“/wp-admin/post-new.php”结尾的 URL 输入这篇文章。但只能说目前如此，未来的 WordPress 已经确定要走向另一条道路。

Mullenweg 还谈到，他希望能在 WordPress 中看到进一步改进——令人惊讶的是，他已经开始从 JavaScript 的视角出发看待这些变化。比如说，PHP 是一种服务器端脚本语言（意味着代码通常在 Web 服务器上处理），而 Mullenweg 希望 WordPress 能使用 JavaScript 把更多操作交由客户端执行。

他意味深长地表示，“我真心觉得我们应该把更多处理任务留在客户端。比如对于正在编辑的内容，这部分处理就可以交给客户端。这种在浏览器运行 JavaScript 的速度可能会更快，因为现在虚拟机和性能极强的处理器已经相当普遍。”

在演讲即将结束之时，有观众向 Mullenweg 询问他对 Gutenberg 项目的感受，以及开发人员为其做出贡献时遭遇到哪些困难。提出这个问题的开发者还希望“降低 Gutenberg 的抽象级别”。

Mullenweg 回应称，“说实施，我觉得大家必须适应这种发展态势。我认为 Gutenberg 的开发方式和 JavaScript 优先理念才是大部分 Web 开发工作的未来方向。顺带一提，其实我也得重新学习，这些东西跟我当初熟悉的方式也有区别。也许我们可以把某些抽象调整得更简单一点，但总体而言，我会选择深入研究一下。”

他还补充称，Gutenberg 项目、包括向 JavaScript 语言的转变，目前还远未完成。“在启动 Gutenberg 项目时，我们就知道这可能是个为期 10 年的项目。目前我们才刚刚完成 60%到 70%的工作。”

不得不承认，WordPress 项目（也是 PHP 能够在 Web 领域保持流行的最大动因）正坚定向着 JavaScript 世界迈进。这几乎必然会阻止更多年轻开发者选择 PHP，同时迫使其他开发人员（例如那些致力于服务 WordPress 客户的开发人员）从 PHP 转向 JavaScript。

但好消息是，仍然有相当一部分开发者群体会继续使用 PHP——毕竟两轮大规模开发者调查中的这 18%对应着相当体量的从业受众。而 PHP 基金会将继续为他们提供支持。

PHP 基金会于 2021 年 11 月正式成立，希望以非营利组织的身份承担起 PHP 项目的管理职责。PHP 基金会是由 JetBrains 领导的企业联盟所建立，其中包括 Automattic、Zend、Laravel 以及 Acquia（Drupal 的托管商）等。JetBrains 工程师 Roman Pronskiy 则出任项目负责人，目前在基金会网站上的头衔为“运营主管”。

在今年 2 月的 Laravel 会议上，Pronskiy 主要探讨了技术问题，同时也承认“PHP 基金会目前最艰巨的任务，就是扭转 PHP 在公众心目中的形象。”虽然他没有具体说明是哪些原因导致 PHP 的公众形象下降，但 Matt Mullenweg 在解释 WordPress 转向“JavaScript 优先”的理由时已经基本给出了答案。无论如何，Pronskiy 正快速投身于 PHP 项目的后续开发，并为其组织起由 10 名有偿开发者组成的全职团队。

PHP 基金会团队

总而言之，2024 年的 PHP 几乎成了 Web 开发领域爹不疼、娘不爱的“孤儿”，而 JavaScript 则是在家、在校都备受关注的宠儿。对 PHP 来说更加可悲的是，目前的这种人气下滑趋势短时间内恐怕无法停止——毕竟 WordPress 那边的开发团队还在积极适应新的 JavaScript 规范。但至少 PHP 基金会还在为此而努力，也许这股颓势能够逐渐迎来转机。

原文链接：

PHP 是最糟糕的编程语言？

我已有将近二十年的编程经验，并使用过各种编程语言进行开发。在我以前做过的很多工作和现在正在做的这份工作中，我非常高兴能够将 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 易于交互，你可以通过各种方式与它交互。希望从 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 坚持软件设计的“正确的方式”，但是这种碎片化导致代码维护和可移植性都受到了影响。

同时，由于 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 语言的优势。

因此，“更糟就是更好”的软件首先会被接受，其次它会使用户期望更少，第三，这些软件将被不断改进，直到接近“正确的方法”的程度。

——Richard Gabrie

在这一启示的几年后，Rasmus Lerdorf 开始研究个人主页/表单解释器，也就是我们现在所知的 PHP。PHP/FI 的诞生是因为 Lerdorf 需要维护他的主页，并与表单和数据库进行交互。PHP/FI 甚至不是作为一种实际的编程语言设计的，而是作为 C 语言之上的一层脚本和函数设计的。

设计一定要简单，不论是它的实现还是接口。

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 倾向于选择“简单”而不是正确。在 HHVM 出现之前，语言的外观和特性一直没有得到规范。Zend 解释器本身就是规范，并且这门语言的行为方式总是 “正确”的（不包括实际的错误）。要想用别的东西代替 PHP 引擎，就必须实现现有引擎的所有特性。

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

看 PHP 语言的发展，几乎所有新特性都是建立在开发人员需要的基础上，而不是“因为它错了所以必须修复”的严肃想法。更多地关注那些严格类型和异常错误是一种更正确的做事方法。然而，还有一些东西，比如简短的箭头函数（arrow function）、属性和枚举，才是开发者想要用来简化代码的东西。

设计一定不能太过不一致。某些情况下，为了保持简单可以牺牲一致性。

我甚至不打算假装 PHP 是一致的，但是它的一致性已经足够了。当涉及到数组与字符串函数时，人们可能会抱怨 needle/haystack 参数顺序。不过，一般而言，数组函数是一致的，而字符串函数也是一致的。与底层 C 库保持一致比在语言中保持一致要简单得多。

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

为了简单起见， 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/

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com