511导航,好用的网址导航

PHP 是最糟糕的编程语言?

7天前

浏览量:10

我有近二十年的编程经验,使用过各种编程语言进行开发。我很高兴在我以前做过的很多工作中,以及在我现在从事的这份工作中,使用PHP作为核心编程语言。从第一次使用PHP开始,就听到了各种关于PHP的抱怨,但同时也看到了PHP的强大。

本文原载于PHPArch网站,由原作者Chris Tankersley授权,InfoQ中文网站翻译分享。

PHP至少是一种有趣的编程语言。这种语言和用它构建的程序通常属于两种设计理念。这里我说的不是软件开发生命周期,比如瀑布或者敏捷,而是软件应该是什么的基本思路。这些思想被称为“正道”和“越坏越好”。

PHP是一种相当奇怪的编程语言。当人们抱怨语言“差”时,他们没有错。这种语言确实有很多缺点。过去,这种语言有更多不好的问题。嘲笑PHP的博文《全面解析 PHP 的槽糕设计》 (PHP :a坏设计的分形)确实有几个正确的观点,尽管这些观点在9年前发表时已经过时了。

然而,与此同时,开发人员可以使用PHP来创建结构上“正确”的软件,并引入被认为是其他语言的良好实践的哲学。像places和Symfony这样的框架使用面向对象编程的最佳实践,这样开发人员就可以使用这些框架编写具有正确结构的代码。

PHP是如何做到这一点的?这是因为PHP是最差的编程语言。

设计软件

1991年,理查德p加布里埃尔发表了一篇文章《Lisp:好消息,坏消息,如何赢得大》 (lisp:好消息,坏消息,如何大获全胜)。本文的论点是,“越差越好”的理念将是软件设计和使用寿命的更好选择。他得出这个结论是因为他意识到编程有两种不同的流派,他将其命名为“麻省理工学院/斯坦福风格”,或“正确的方式”,以及“新泽西风格”或“越差越好”。

这两种哲学有相似的目标,但在关键领域有所不同。这两种风格都专注于哲学的四个关键领域:简单性、正确性、一致性和完整性。

麻省理工学院的风格描述如下:

简单性:设计必须简单,不管它的实现或接口如何。相比之下,保持界面简单更重要。准确性:在所有可观察的方面,设计必须是正确的。不要试图做出不正确的设计。一致性:设计不能不一致。为了确保一致性,您可以稍微牺牲简单性和完整性。和一致性同样重要。完整性:设计必须涵盖尽可能多的重要情况。必须涵盖所有符合预期的情况。正直应该优先于简单。至于新泽西风格,加布里埃尔表示,其目标定义为:

简单性:设计必须简单,不管它的实现或接口如何。相比之下,保持实现简单更重要。简单是最重要的,其他特征没有保持简单重要。正确性:设计必须在所有可观察的方面都是正确的。但是为了简单,可以稍微牺牲准确性。一致性:设计一定不能太不一致。在某些情况下,可以牺牲一致性来确保简单性。如果在设计中引入不寻常的情况会导致复杂或不一致的实现,不要考虑这种情况。完整性:设计必须涵盖尽可能多的重要情况。必须涵盖所有符合预期的情况。完整性可以让位于任何其他特性。事实上,一旦实现的简单性受到威胁,就必须牺牲完整性。为了保持简单,我们可以牺牲一致性来实现完整性。尤其是接口的一致性。这场争论的关键是用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/

0
评论内容: