编程界的丰田卡罗拉

图0:编程界的丰田卡罗拉

1995年,一位名不见经传的软件开发者发布了新型脚本语言的首个版本,其明确目标是为名为“万维网”(The World Wide Web)的新平台开发应用程序。该项目最初规模较小,但得益于互联网泡沫时代的狂热,它迅速发展成为有史以来使用最广泛的编程语言之一。经过最初的蹒跚学步,该语言最终在1997年实现了某种程度的标准化,甚至不情愿地加入了一些面向对象编程(OOP)特性,以取悦社区和评论家。

然而,无论它如何努力,这种语言及其用户多年来一直被所谓的“严肃”程序员嘲笑,他们嘲笑其“WTF”级别的语法、运行时模型的怪癖、不断增加的安全问题,以及围绕它涌现的无数框架。尽管面临强烈反对,这门语言及其社区最终挺了过来,并迎来了一个巨大的第二春,甚至得到了大型科技公司本身的明确支持。如今,随着这门语言迎来30周年的辉煌时刻,一个新项目正凭借Go编程语言的优势推动其未来演进。

元素周期表

有趣的是,上述两段描述不仅适用于一种,而是两种编程语言:一方面是PHP,它深受Perl启发并于发布由拉斯穆斯·勒多夫(Rasmus Lerdorf)于1995年6月以“个人主页工具”(Personal Home Page Tools)之名发布; 另一方面,JavaScript 由 Brendan Eich 设计,并于同年 12 月由 Netscape 发布

但这两种语言之间的相似性不仅限于此。1997年,这两种语言都通过PHP/FI 2ECMA-262实现了某种程度的标准化。。在2010年代,这两种语言分别获得了Facebook、Google和Microsoft的大力支持。到了2025年,它们都基于Go编程语言进行了重大改造:一个名为FrankenPHP的新PHP运行时,以及最近宣布的TypeScript编译器

PHP和JavaScript代表了同一枚硬币的两面:网络编程,包括服务器端和客户端。万维网(World Wide Web)的兴起使它们成为重要角色,尽管它们(坦白说)最初的设计缺陷相当明显,演进过程缓慢且依赖委员会决策,以及各自生态系统中层出不穷的安全漏洞。

C++ 创造者 Bjarne Stroustrup 经常被引用的一句微笑

只有两种语言:一种是人们抱怨的,另一种是没人使用的。

两年前,我们曾发表过一篇关于BASIC的文章,这种编程语言是所有开发者又爱又恨的,但它单枪匹马地定义了我们行业的一个时代。我们理应为PHP留出一些篇幅——这种同样被众人抱怨、被众人嘲笑的语言,却据称支撑着全球70%至80%的网站; 毋庸置疑,这是一个令人印象深刻的数字,无论你如何看待它,无论多少“严肃”的程序员如何嘲笑它。

纵观历史,编程语言曾获得过一些有趣且发人深省的绰号。C语言被称为“可移植的汇编语言”。Java 适合“写一次,调试到处”。Python 通常被称为“可执行的伪代码”。JavaScript“在10天内创建,这一点显而易见”。Perl是“互联网的胶带”

至于 PHP,它要么是“糟糕设计的分形”( seriously, people? ),要么是“Pretty Horrific Programming”的缩写。哎哟。

以下是我的看法:PHP 是经济实惠的云网络托管服务的通用语言;或者换句话说,它是编程语言中的“丰田卡罗拉”:平淡无奇、可靠稳定、易于使用且价格亲民。几乎在世界任何地方,你都能找到提供 LAMP 圣四重奏的经济实惠网络托管服务: Linux、Apache、MySQL 和 PHP;一个操作系统、一个网络服务器、一个数据库服务器和一个脚本语言,以低廉的价格打包在一起,使大众能够走得更远。引用乔治·克鲁尼的话来说,还有什么别的呢?

如今,PHP 具备现代编程语言的许多特征;让我们来列举一些,首先是从其完全 开源 的性质开始。它具有先进的 OOP 功能,如 traitsproperty hooks命名空间属性枚举。它包含函数式编程构造,如带捕获列表的闭包箭头函数,以及一个“管道”运算符(将于今年11月推出)(OCaml 和 F# 开发者们,欢呼吧!)。PHP 支持关联数组,并拥有一个虽简单但快速、实用且不断发展的类型检查系统 (记住:declare(strict_types=1); 是你的好帮手),包括 never可空类型。它内置了一个完整的算法库,遵循“开箱即用”的理念,如果其他方法都行不通,还有一个强大且开源的包管理器,拥有足够多的包npm 汗颜。它对单元测试提供了卓越的支持。作为脚本编程语言,它的编译和执行速度相当快。它拥有自己的生态系统,包括会议、吉祥物以及由JetBrains开发的强大IDE

然而,它确实包含goto 语句。哦,天啊!迪杰斯特拉会怎么说!更不用说那些烦人的以美元符号开头的变量,以及令人尴尬的foreach 语句。真是耻辱!

大多数所谓的“严肃”程序员都应该从他们的象牙塔中走出来,看看 2025 年的 PHP,以免被大语言模型(LLM)取代工作。过去十年间,该语言经历了重大、稳步且持续的更新,包括每年11月发布一个稳定版本的节奏,以及一个专门团队持续修复安全漏洞,并用更新、更安全的API替换过时的API。

我知道他们应该重新审视PHP,因为我本人也曾不得不走出自己的象牙塔,去做这件事。我必须坦率地承认我的过失:早在2009年,我曾参与过一个(坦白说毫无意义的)社区活动,名为“我讨厌PHP”(互联网档案馆已妥善保存了该活动的副本),我的名字在首页上醒目地出现。我认罪,法官大人。

作为辩解,我将指出那正是PHP较为黑暗的时代。那时正是布鲁斯·泰特(Bruce Tate)的《超越Java》(Beyond Java)及其书中对PHP的漫长抨击盛行的时期。

还记得早已消失的PHP安全联盟吗?小鲍比表的时代是否已经结束?让我们坦率地说,其实并没有。如果你想的话,你仍然可以发布包含SQL注入漏洞的代码(提示:尽量避免使用.运算符。对于所有非数据库查询的操作,字符串插值是你的好帮手)。

Rt. Rvd. 牧师曼努尔·拉弗罗伊格在其讲道中,向“奇异机器第一联合教会”的挚爱会众宣称,每种编程语言中都蕴含着神性……包括PHP:

如果像 PHP 这样的语言能让如此多的人接触到黑客技术,那么这就是它的神圣之处。它为孩子们提供了一个学习程序执行如何出错的第一步,因为控制和数据如此容易被篡改。

阿门。

如今,我所看到的是一群健康、蓬勃发展的PHP社区。除了JetBrains之外,这个社区并未受到FAANG或其他任何“科技巨头”公司任性的影响。而PHP基金会正在推动其标准向未来演进,希望能在金钱与人之间的不稳定领域中找到平衡。

请谨慎看待这些数据,但若观察语言排名,仍有大量市场待重新夺回:在TIOBE指数中,尽管PHP曾被评为2004年年度语言,但目前它在第15位且呈下降趋势:2010年它曾位列第3。在IEEE排名中,它位列第13位,而在PYPL排名中位列第7位,与过去20年相比,这一排名有所下降。不过, 在RedMonk排名中,它位列第4位,而图表显示,自2013年至今的下滑幅度并未如此剧烈。并非一切都已失去!

开玩笑归开玩笑,PHP历史上最重要的进展与驱动它的引擎有关。几十年来,Zend引擎一直是该语言演进的标杆; 该引擎专为1999年万维网的需求设计(当时是LAMP架构的时代),尽管它在当时表现出色,但无法顺畅地适应DevOps、容器和Kubernetes编排器的时代。

(如果你曾经尝试过使用 Dockerfile 搭配 Nginx、FPMSupervisor 来运行某个被遗忘的 PHP 7.1 应用程序,请举手。我感同身受,朋友。)

幸运的是,我们现在可以摆脱Zend了。得益于其社区不可预测的强大力量,有一个名为FrankenPHP的项目。该项目最近已被PHP基金会采纳为官方运行时,它具备所有能推动PHP进入新阶段的条件。

FrankenPHP不仅极大简化了容器的创建过程,还为PHP代码提供了新的执行模型,同时与现有的庞大代码库保持100%兼容。本月我们在Vidéothèque板块中对FrankenPHP进行了更详细的探讨。

尽管 FrankenPHP 非常出色,但我并不期待对 PHP 的负面评价会很快消失。该语言将继续承受其 humble 起源带来的污名。Rasmus Lerdorf 并未在 “Masterminds of Programming”的采访,因为PHP是典型的在集市上诞生的语言,是偶然设计的产物。拉尔斯也不会受邀参加下一届HOPL大会,尽管该语言拥有不合理的 popularity,PHP也不会被用于博士论文(除了与安全相关的论文)。雪上加霜的是,PHP甚至未在《编程之道》中提及(好吧,好吧,该书出版于1987年,我承认这一点)。

但值得庆幸的是,IEEE的《计算机杂志》确实关注了PHP,并跟进对拉斯穆斯的采访,以文字视频 两种格式,于2012年发表。

至少如此。在这篇采访中,拉斯穆斯阐述了“集市”背后的核心哲学:

我在过程中逐渐意识到,为了让PHP发展壮大,我必须放弃对PHP的控制权——我必须让其他人也拥有部分控制权。 (…) 这不仅仅是他们为我的项目做贡献——它变成了我们的项目,这真正改变了PHP的本质。

共有 191 条评论

  1. Java 更像是丰田卡罗拉。它设计得毫无特色(这是刻意为之),与马自达3等竞争对手相比缺乏精致感,适合那些只把它当作从A点到B点的交通工具的人。

    PHP是编程界的现代伊兰特。它曾因低成本而流行,但因设计缺陷和可靠性问题长期成为笑柄。但就像伊兰特一样,它已今非昔比,如今表现尚可。

    • 这在很多方面都低估了现代卡罗拉。

      例如,自2023年起,标准版卡罗拉已配备一套自动驾驶辅助技术,其性能远超马自达在最高配置下的任何同类系统。

      唯一通过62英里/小时至完全停止的自动紧急制动测试(未来标准)的车型是丰田卡罗拉。

      • 我认为这是一个相当贴切的类比——我认为可能比它更好的编程语言只有Go。

        丰田卡罗拉是工程设计极为精良的车型。关键在于,它们的设计理念是围绕_便利性_、_可靠性_和_性价比_展开的。丰田明确放弃了那些看似炫酷但会增加汽车复杂性的花哨功能,因为复杂性通常会带来成本和不可靠性。因此,你得到了一辆驾驶起来无聊、乘坐起来无聊的汽车,但它极好地完成了汽车的主要目的(以低成本和安全的方式将你从A点带到B点)。

        同样,Java 也极具工程设计精髓。如果你曾深入研究过 JVM 或类库的内部实现,会发现其中蕴含了大量深思熟虑的设计和先进技术。但它被设计成“无聊”的。其目的是让大型企业中的普通程序员能够高效工作,同时避免犯下重大错误。

        我之所以说Go可能是更好的类比,是因为Go同样设计得极为精良,但它是为了在大公司普通程序员使用时确保可靠性而设计的。Java在多线程和异常处理方面仍然存在不少潜在风险。Go 只是说:“我们将使用经过实战检验的 CSP 进行并发处理,并且要求每位程序员明确处理每个错误情况,即使这意味着要编写大量冗余代码,因为如果不让工程师主动思考,他们就会出错。” 这与丰田卡罗拉的类比非常贴切,卡罗拉同样非常注重确保半熟练的机械师和非专业司机必须明确思考自己的操作,否则就会出错。

        • > 丰田卡罗拉是工程设计极为精良的汽车。问题是,它们的设计侧重于便利性、可靠性和性价比。

          对我的2007款丰田卡罗拉来说,这可说不通。它经历了半打召回,传感器问题不断,还有一系列其他问题,比如众所周知的链条问题。

          “设计精良”这个词真的不适合我的2007款卡罗拉。是的,我的1992款卡罗拉像坦克一样结实,但不是“现代”的2007款。

          > 经济实惠?

          你是说现在基础款卡罗拉要33000欧元吗?我认为人们还停留在90年代卡罗拉的思维模式中,因为现代卡罗拉是昂贵的车型。

          最糟糕的是,这甚至不是一款好的混合动力车。一款配备1080公里实际续航里程、全套电子设备、太阳能车顶等配置的比亚迪SUV在这里售价36,000欧元。当一款不算大的掀背车都这么贵,而一款SUV却……

          • 你听起来对你的卡罗拉很不满意。如果我是你,我会把它卖掉。

            不过,一辆20年的车有6个问题,听起来并不算太糟糕。

            编辑:顺便说一句,你很容易就能以不到23,000欧元的价格买到一辆2023款卡罗拉。

          • 如果我今天想买一辆车,最好是电动的,就像90年代的卡罗拉一样,我应该买什么?没有像DRM或反维修功能这样的客户敌对功能是其中的一部分。

            • 斯巴鲁现在非常可靠。我认为他们现在只有一款电动车型,但另一款即将推出。

        • 这种情况已经不复存在了,丰田不再是那家公司。

          目前他们只是在生产工程设计更优的汽车,这并非因为他们的零部件保守。他们的技术并未落后,事实上,在这一特定领域的“大众化”汽车中,他们的技术处于领先地位。

          即便如此,丰田仍是一家整合者。他们并未对供应链实现垂直控制。他们并非比其他公司领先或不同,只是优先级不同且拥有更雄厚的资金储备。

          豪华车领域确实领先,但这并非争议焦点。

        • 我认为围棋是一个更好的类比,因为它也摒弃了那些会增加复杂性的花哨功能。虽然Java语言本身确实旨在保持相对平淡,但JVM却带来了大量复杂性,需要相当长的时间才能驾驭(例如,JIT编译器花了一段时间才将性能提升到合理水平,而垃圾回收机制则耗时更久)。

      • 现代卡罗拉,就像大多数竞争对手的车型一样,是一辆好车、安全、高质量、可靠的车。这些品质并不与“平淡无奇”相矛盾。卡罗拉的内饰感觉实用,功能简洁,驾驶动态……温和。

        它完美地完成了作为交通工具应有的功能,且完成得相当出色。然而,兴奋感与个性化设计并非其设计考量。

        • 该描述仍不准确。

          卡罗拉在现代功能的实现上优于马自达3,只是缺乏后者的炫酷感。

          • > 卡罗拉在现代功能的实现上优于马自达3,只是没有那么抢眼。

            作为一名每天驾驶2024款马自达3 PP的车主,并与邻居(他每天驾驶2024款卡罗拉XSE掀背版)进行试驾和对比,我认为这种描述完全不准确。我对卡罗拉并无偏见,但与马自达3相比,卡罗拉在许多方面都存在不足。

            一个简单的例子是,我的马自达3配备了抬头显示屏(HUD),可将车辆安全系统数据、分步导航(来自Android Auto、Apple CarPlay或内置导航)、速度数据和车辆数据投射到HUD上,因此我无需低头查看仪表盘。

            另一个例子是,虽然马自达3在中央控制台上配备了触摸屏,但每个功能都有物理按键,触感良好,而且马自达选择在车速超过5英里/小时(默认设置)时禁用触摸屏,确保你在高速公路上驾驶时不会因使用触摸屏而分心。

            至于所有这些自动安全系统,大多数都是政府强制要求的,每辆车都配备了这些系统。我同意丰田在这方面做得比大多数制造商更好,但据我所知,我邻居的2024款卡罗拉上没有一个系统是我的2024款马自达3上没有的……

            在我看来,卡罗拉的优势在于其简洁性。马自达3的内饰设计过于复杂,但又似乎不够到位,结果导致驾驶体验虽然舒适,但偶尔会出现面板异响,这并非高端体验。卡罗拉的内饰则更为基础,非常普通,但它在执行普通设计时却毫无瑕疵。

            至于驾驶动态,两者根本不在一个水平上,马自达3明显更胜一筹。唯一拥有出色驾驶动态的卡罗拉是GR卡罗拉,但那完全是另一种类型的车。

          • “平淡无奇”这个词与“良好的实现”无关。

            • 没错,这就是为什么你专注于这一点,而不是其他两个主张。

              >与马自达3等竞争对手相比缺乏精致感,而且是为那些只是把它当作从A点到B点的交通工具的人设计的。

              当然,我也不同意它乏味的说法,这在现代丰田车型中也是不准确的,但这是另一个讨论。

              • 从上下文来看,他们使用“精致”一词是指发烧友的品味。他们并非在说丰田是粗糙的车辆。无论你如何看待,他们的陈述在行业评测和两大品牌自身价值主张中都具有很强的说服力。

      • 这个兄弟评论也在为Java的发展方向辩护。

      • 我最近在欧洲租了一辆卡罗拉。它配备了大量驾驶辅助功能,而这些功能简直一无是处(我认为这是欧盟监管机构强制要求的)。每次启动车辆时都要关闭所有这些功能,这让人非常烦躁,我不知道有人如何在启用这些功能的情况下驾驶这些车辆。

        仪表盘不断闪烁。它闪烁是为了告诉你限速发生了变化。它闪烁是为了告诉你前方有人行横道。这些警报声形成了一片喧嚣,让人立即感到疲惫,使得所有警报都变得毫无意义。

        汽车不断发出蜂鸣声。它蜂鸣是为了告诉你限速发生了变化(在许多地方,每分钟都会发生多次)。在许多地方,限速变化并未明确标示,而是隐含的——例如高速公路上的每个匝道,限速会因匝道而降低,然后在通过匝道后再次提高。系统会持续蜂鸣,提示你超速1公里/小时,并且蜂鸣声会持续至少5秒,甚至可能长达10秒。

        它会不断地拉动方向盘,当它认为你离白线太近时。我告诉你,在道路狭窄的国家,你总是离白线很近。它会把你拉向迎面而来的公交车,因为你偏离得太远,靠近了对向车道。它会把你拉向超车的车辆,因为你敢给更快行驶的车辆让路(在东欧地区经常看到这种情况)。

        我最近租的车大多是丰田,通常是混合动力车型(RAV4、Corolla Cross、Corolla)。

        给我一辆马自达。

        • 有趣的是,我之前听说过这件事,但直到和我的岳父一起开车时才真正明白。他开车就像个精神病人。

          他的仪表盘不断闪烁,警告他即将发生危险。而警告是正确的,因为他习惯了错误的驾驶方式。

          当然,他很久没有发生事故了——但这更多是靠运气、他能游走于危险边缘的能力,以及他人的警惕性。

          我拥有一辆现代丰田车,从未被安全功能困扰。

          我拥有它,只是因为我对汽车不感兴趣,而这辆车就是这样。

          • | 他的仪表盘不断闪烁,警告他即将面临危险。而这种警告是正确的,因为他已经习惯了错误的驾驶方式。

            在我驾驶过的汽车中,仪表盘的闪烁与驾驶方式无关。限速变化、人行横道提示等情况都会触发警示。(除非你关闭这些功能——不过在国外,由于我不太了解当地习俗,我愿意忍受这些烦扰以减少与当地警方发生冲突的风险。)

            唯一例外是,如果你敢超过标示(或有时是想象中的)限速,限速提示灯会继续闪烁。

            • 可能我的车(2023年北美市场日产电动汽车)只是不太“爱说话”,但作为一名相对新手司机,我发现自己不得不改变驾驶习惯以避免触怒这台机器。如今它很少再对我抱怨了。

              • 可以说其中一些功能是有用的(速度?尽管我不想承认)。

                我认为“不要在车道边缘附近驾驶”并不是一个好习惯。靠近车道边缘甚至越过车道边缘有很多很多很多安全理由,我不确定训练司机始终保持在车道几何中心是否 helpful。例如,这是我最讨厌自动驾驶功能之一,车辆试图过于激进地保持居中。

      • 你肯定很久以前就试过马自达了 🙂

        • 不,我了解这两项技术及其实现方式。

          我曾试驾过马自达3给我的孩子,它有一些仿豪华配置,但本质上是一辆劣质汽车:技术实现更差。

          马自达没有投资于动力总成技术,因此他们使用丰田的动力总成。马自达没有投资于ADAS软件,所以他们几乎没有努力。马自达没有投资于一个体面的悬挂实现,所以他们的3系列使用了一些可怕的扭力梁垃圾,感觉完全不精致和消费级。

          糟糕。

          • > 马自达没有投资于动力总成实现,所以他们授权使用丰田的。

            ??? 马自达有自己的动力总成开发,马自达3上没有任何与丰田共享的部件。唯一与丰田共享动力总成的公司是斯巴鲁和宝马,通过它们在BRZ/GR86和Z4/Supra上的合资企业。

            > 马自达没有投资于良好的悬架系统,因此其3系车型使用了一些糟糕的扭力梁悬架,感觉完全粗糙且缺乏质感。

            马自达在马自达3上使用了扭力梁后悬架,这是事实。虽然独立多连杆悬架在理论上可以提供更好的操控性,但这依赖于悬架臂的可调性,以便根据预期路况和所用轮胎调整几何参数。换句话说,对于大多数不提供后悬架调整或仅提供 toe 调整的量产车型而言,这基本上无关紧要。我这么说,是因为我曾以赛车为业余爱好,投入了大量时间、精力和金钱来学习悬架设计,至少与机械工程专业本科生掌握的知识相当。我曾用软件模拟赛车的悬架系统,并与一家车间合作开发并生产了具有全可调功能的定制悬架臂,以匹配我理想中的几何参数。

            尽管马自达3后悬挂采用技术上“较差”的扭力梁悬挂,但在弯曲道路上的操控表现仍优于丰田卡罗拉XSE。

            EDIT:我收回前言,马自达为CX-50混合动力跨界车授权了RAV4混合动力传动系统。这当然与马自达3完全无关,后者是一款截然不同的车型,几乎所有关心传动系统的买家都会选择2.5升涡轮增压发动机和PP版本以获得四驱系统,但谁会在乎呢。

            • 如果帖子的核心内容得到纠正,我本可以直接删除它。

              马自达之所以授权使用动力总成,是因为他们是一家小型公司,研发投入有限。他们实在无法生产出优质产品。

              • 他们的赛车血统和在热 hatch 类别中的长期地位与你意见相左,基本事实也是如此。

                你现在已经把自己定位为一个怀有偏见的白痴,而不是以善意进行互动。

    • 现代Java现在相当不错,对吧?类型推断、纤维、文本块、记录……

      如果我们讨论的是Java 8(我毫不怀疑很多人不幸仍在使用它),我同意你的观点,但与过去相比,我对现代Java环境的接受度要高得多。

      • 你提到Java 8作为负面例子挺有趣的,我记得它曾被广泛誉为一个姗姗来迟的正确方向,带来了一股清新的空气。

        • 我认为他们只是想说新版本是朝着这个方向的进一步发展,而不是说Java 8是错误的一步。

        • 没错。Java 1.8 是朝着正确方向迈出的巨大一步。

      • JVM 及其生态系统是 Java 平台的最佳部分。不是语言本身,我甚至不再使用它,而我几乎 100% 基于 JVM。但即使如此,它仍然不算糟糕。只是有更好的选择,比如 Scala。

    • 这个比喻很贴切,但比喻中的例子有点糟糕,哈哈。(不喜欢吹毛求疵)

      在两者中,马自达3会是“更实用、更便宜、更可靠”的选择,尤其是在2025年。

      我也不记得卡罗拉曾因设计或维修能力而缺乏信任的时期;我的大伯父总是谈论他“第一辆真正的全新汽车”是一辆69款卡罗拉,那是一辆耐用的车。这为80年代末日本车在美国的普及铺平了道路。

    • Java更像本田。它无处不在,超可靠,技术足够无聊,以至于人们无法忍受它,因为它根本不代表任何东西,尽管所有试图取代它或推翻它的努力,它继续卓越并发展。

    • 你擅长类比。

      你能告诉我哪辆车是Python吗,这样我就可以把它加到我的购物清单上?

      • > 你能告诉我哪辆车是Python吗,这样我就可以把它加到我的购物清单上?

        悍马H3。当悍马推出时,它在某些方面表现得异常出色——比其他任何车型都好——尽管在速度、外观等许多方面表现糟糕。它很受欢迎,因此他们后来推出了一款以原名命名的后续车型,但该车型与原版使命不符,希望那些曾渴望拥有第一代车型的消费者会继续追随;而不知何故,这种策略奏效了。

      • 一辆梅赛德斯-奔驰Sprinter。它被用于各种用途。从简单的配送到极客露营。虽然不是最快的,但它具有高度的模块化,可以作为日常用车、工作用车或休闲用车。

        • 我认为Sprinter更像Fortran。你会在需要搬运大量物品时使用它,尽管它本身速度不慢,但你既不会为了娱乐而驾驶它,也不会只在需要搬运少量物品时使用它。

    • 那些卡罗拉(Corolla)配置简陋的时代早已一去不复返,即便如此,它也比马自达323(Mazda 323)更胜一筹。

      • 我曾驾驶一辆2009款卡罗拉SE长达三年。它唯一的优点是维护和修理费用极低。除此之外,它在高速公路上反应迟钝,操控如购物车般笨拙,时速140公里时极不稳定,内饰设计更让人时刻记得自己并不富裕。

        丰田无法制造出有趣的汽车——这根本不在他们的基因里。这就是为什么他们所有的运动型汽车都是由其他公司(斯巴鲁和宝马)生产的。

    • Java更像福特F-150而非卡罗拉

  2. PHP之所以成功,只有一个原因:它真的、真的、真的非常容易部署。当然,这被懂行的程序员低估了,但我记得刚开始做网页开发时,我能在几分钟内就把真正的程序(!!!)放到网上!

    我认为它更像自行车。便宜,无需执照,即使是个孩子也能突然在城里飞驰,无需繁文缛节,无需审批,投资极少。

    我已经十多年没用过它了,但仍然怀念它作为通向更大更好事物的大门药物是多么棒。

    • 我无法对这个赞同得更多。零摩擦就像超导性:一个巨大的、质的飞跃。如果做关键事情变得极其、荒谬地容易,人们就会轻易原谅产品可能存在的任何缺点,无论是像Docker这样的专业工具,还是像Twitter这样的大众服务。

      (做一件事,但要做好;听起来很熟悉?)

    • 没错。当时我正在编写Perl CGI脚本,而在上传脚本、赋予其可执行权限以及设置需要写入的文件权限等部署过程中,常常会遇到各种问题。将PHP直接集成到Web服务器中,而不是使用外部CGI脚本,消除了很多这些问题,因此它更可能直接正常工作,而无需与Web管理员来回沟通以正确配置CGI环境。问题不在于语言本身,而在于部署方式。

      • 没错!这确实是个重大进步。你可以从编码到上传再到刷新应用程序,速度快得令人惊叹。别忘了,使用Perl CGI时,你必须在输出页面内容的顶部正确输出Content-Type头部(并添加两个换行符),否则浏览器无法正确解析页面内容。

    • 在互联网上关于PHP的诸多调侃中,有一句话让我印象深刻——“任何傻瓜都能写PHP,而且确实有很多人这么做”。这既因为它很有趣,也因为这种较低的入门门槛实际上是一件好事。我希望“任何傻瓜”都能编程,如果PHP支持这一目标,那它就更强大了。

    • 完全正确。我记得当时的替代方案是设置Tomcat、JBoss等服务器并处理所有那些繁琐的事务。

      感谢上帝,我们大多数人不必长期应对那种企业级垃圾,而我的情况也得益于PHP。

  3. PHP对我来说很难描述。我在90年代末大量使用它,当时我们正在从mod_perl迁移,因为它是一种在静态页面中添加动态数据的绝佳方式,而当时没有人真正知道如何开发大型网站。我们是在边做边学。但天啊,这门语言太糟糕了。“拙匠怪工具”之类的说法,但想象一下一把螺丝刀,它有两个手柄和三个以随机角度突出的刀头。当然,你可以用它组装一张宜家桌子,但你会想用它吗?当同一个地方提供免费的Snap-On螺丝刀时,你会对声称喜欢那把奇怪螺丝刀的人感到怀疑吗?

    我认为这就是恐怖的根源。没有人会对使用PHP添加一些服务器端内容感到惊讶。它很适合做这件事!但当你看到用它建造的非欧几里得恐怖城堡,人们指着它们说“看看你能用那把奇怪的螺丝刀建造什么?”,而城堡的某些部分会随机脱落并杀死它们的主人时,情况就不同了。不!虽然这很令人印象深刻,但它并不能让人对这把螺丝刀,或者那些继续用它来建造超出其能力范围的大型结构的人产生信心。但如果你指出还有更合理的螺丝刀,天啊,你可就倒霉了。“你只是思想封闭、与时代脱节!我们给它加了个把手,去掉了剃刀片,现在好多了!”

    也许吧,但天啊,它仍然是一把非常奇怪的螺丝刀。

  4. 其他语言后来赶上了PHP。

    据我所记得,早期允许在HTML中直接编写代码的语言都是专有技术,例如内置于Netscape网络服务器中的服务器端JavaScript、ColdFusion、ASP等。

    PHP 是其中第一个开源且基本成熟的语言,这使其成为我 2001 年开发网页应用的首选。与许多其他语言(如 cgi-bin)相比,它无需编译步骤且运行速度较快,同时具备足够的资源管理能力,使得主机服务商能够提供廉价的 PHP 主机方案,从而使 WordPress 等改变世界的开源产品得以部署。

    它很快变得过时,因为人们意识到,要制作高质量的网络应用程序,你需要框架的一部分(一个“路由器”),它可以根据输入提供不同的页面。例如,如果你在表单上进行服务器端错误处理,你either显示一个显示“成功”的表单,或者重新显示表单并附带错误消息。当然,如果你有足够的纪律性,你可以用PHP实现这一点,但一旦引入路由器,你最好使用某种模板系统来编写“视图”。在Ruby on Rails之后,每种语言都出现了类似Sinatra的框架,这些框架与PHP一样易于使用,这迫使你养成良好的编程习惯。

    • 其HTML内联特性正是我使用它的全部原因。在21世纪初的某个时刻,我遇到了PHP的include功能,这让我感觉像是终于找到了HTML中一直缺失的那块拼图。突然间,我无需再手动在N个页面中同步所有头部/导航/底部代码!简直神奇。

      直到Rails出现,我才开始构建类似于“真正”的网络应用程序。它带来的结构和规范使得它比PHP更加易于上手,因为当时所有更复杂的PHP示例都像是混乱的意大利面代码,难以理清并作为学习的示例。

  5. 作者指出,该语言已不再是2009年那种糟糕设计的代名词,但并未为2025年启动一个全新项目使用它提供充分理由。

    它比其他语言更擅长什么?文章提到的功能听起来与其他现代语言处于同一水平,但没有特别突出的地方。

    • > 它比其他语言做得更好的地方是什么?

      无共享架构。如果你使用例如FastAPI,你可以将一些数据存储在内存中,这些数据将在请求之间可用,如下所示

          import uvicorn, fastapi
          
          app = fastapi.FastAPI()
          
          counter = {“value”: 0}
          
          @app.post(“/counter/increment”)
          async def increment_counter():
              counter[“value”] += 1
              return {“counter”: counter[“value”]}
          
          @app.post(“/counter/decrement”)
          async def decrement_counter():
              counter[“value”] -= 1
              return {“counter”: counter[“value”]}
          
          @app.get(“/counter”)
          async def get_counter():
              return {“counter”: counter[“value”]}
          
          if __name__ == “__main__”:
              import uvicorn
              uvicorn.run(app, host="0.0.0.0", port=9237)
      

      这是解决眼前问题最快捷的方式,但会让后续逻辑变得难以理解。PHP在请求之间不保留任何数据,因此所有需要在请求之间持久化的数据都必须显式地存储到特定的外部数据存储中。

      当然,非 PHP 工具链在正确使用时也提供相同的优势。然而,PHP 在这一点上更难被错误使用,而根据我的经验,消除这一类错误的优势与我天真地认为在经验丰富的开发者编写的代码库中很少见到这种错误相比,是令人震惊的巨大。

      • 我之前从未从这个角度思考过 PHP。但它作为文本预处理器的起源,使其成为无状态设计的天然组成部分。如今 everyone 都希望所有数据始终被持久化,这导致了疯狂的状态问题。

        • 这也是因为它是一种为网络设计的语言,而HTTP是无状态的。

      • 但那是Python,对吧?

        编辑:哦,你用Python举了个例子!现在我明白了!

    • 我认为优势基本上和以前一样。

      1. 轻松部署——尤其是在共享主机上 2. 请求之间不共享任何内容,这意味着轻松实现并发和并行处理 3. 与 HTML 混合使用意味着你不需要单独的模板语言

      并非所有人都认为第三点是优势,许多网络框架,包括 PHP 框架,更倾向于使用单独的、更严格的模板语言。这可能是个陷阱,但有时非常方便。

      • 我认为#1已经过时很久了。通过FTP或CPanel复制文件从未比使用`fly deploy`等工作流更方便,后者甚至无需了解远程文件系统或已运行的服务器。而Nginx调用PHP-FPM也比直接执行“node script.js”或运行编译后的Go二进制文件更复杂。

        虽然我从未真正想要过,但#2在精神上还是挺酷的。CGI或Cloudflare边缘 worker也是如此。

        • 手动复制文件的人不会使用更复杂的工具。这并非我所想,我认为这并非公平的比较,更不用说昂贵且专有的平台了。

          如今,人们更可能使用git pull或rsync。

          > 通过nginx调用php-fpm比直接运行“node script.js”或编译后的Go二进制文件要复杂得多。

          据我所知,Apache搭配mod_php仍是可选方案。在共享主机上,预配置好所有设置也非常容易。还有FrankenPHP。

          这可能不是对每个人来说最简单的选择,但对某些人来说确实如此。

      • 我认为1是个误区。只要你不介意原子更新,部署起来其实很简单,比如新上传的foo.php文件导入尚未上传的bar.php。解决这个问题,比如通过一个DAG来确定上传文件的顺序,那么它就不再比其他方案更简单了。

        就像其他许多事情一样,PHP 使做错事情比其他语言更容易,而其他语言会迫使你正确地做同样的事情。

        • 我曾在一家公司工作,他们将 git pull 作为发布流程——那是一个大型网站,但我从未听说过有任何问题(尽管代码处于维持状态,因此没有发生重大更改)。

          他们为新网站切换到了蓝绿部署(我怀疑这是在服务器级别完成的,而不是通过符号链接或其他类似方式)。

        • > 只要你不介意原子更新,部署起来就很简单

          如果可以接受一些停机时间,这重要吗?

          • 不,但这会大幅改变目标。与部署包含 Python 应用或 Rust/Go 二进制文件的新 Docker 容器相比,“只是复制一堆文件”确实更简单。但前者也远不如后者健壮。

        • 难道不上传所有文件到 v2 目录并重命名目录更好吗?

          • 也许可以。你可以通过原子操作移动符号链接,使文件系统视图始终只查看旧文件或新文件。

            然而,即使这样也无法处理正在处理中的请求,因为这些请求的文件视图可能会在处理过程中被替换。虽然错误发生的时间窗口很短,但绝非瞬间完成。

            更安全的解决方案是更新服务器配置以指向新目录并重新加载Web服务器,但此时你已经远远超出了仅仅上传新文件的范围。

            • 这几乎是即时的。正在处理的请求仍会以旧版本完成,因为已执行的代码已存在于内存中。

              我认为这与更改代理以指向不同端口没有什么不同。

              • 这并不完全正确。想象一下一些(糟糕的)代码,比如:

                  $conn->query(‘SELECT * FROM giant_table ORDER BY foo LIMIT 1’);
                  require ‘old.php’;
                

                这样,请求生成与后来包含另一个文件之间会有一个显著的间隔。查询的持续时间为'old.php'消失提供了机会,这将导致500错误。

                区别在于你可以同时监听两个端口,并在第一个端口连接耗尽后关闭它。

                没有一种根本上安全的方法可以升级一个基于文件的PHP应用程序,除非使用复杂到足以与另一种语言的部署相媲美的工具。

                • 我不认为 PHP 是这样工作的(至少现在不是)。当请求发出时,代码首先会被编译为操作码,只有在编译完成后操作码才会被执行。在大多数生产环境中,这些操作码甚至会被缓存,因此即使你删除了项目,它仍然会运行。

                  无论如何,你必须在 opcache 生成的几毫秒窗口内才能中断单个请求,但即使这样也可能不太可能,因为文件系统读取文件的方式?

                  • 在那个例子中,我确信 ‘require’ 语句会被编译为 opcodes,但直到该语句被执行时才被执行。支持证据:https://stackoverflow.com/questions/37880749/when-is-a-php-i

                    因此,如果从执行开始到 ‘require’ 语句被到达并评估之间有 10 秒的间隔,那么在这 10 秒内对被要求的文件进行任何不兼容的修改都会导致错误。

                    • 这实际上是有道理的,因为代码路径可能非常庞大,包含大量未使用的代码。

                      使用OpCache可以解决这个问题,所以我猜对我来说的教训是——在启用OpCache的情况下进行部署。

                    • 嗯,现在你只需要管理缓存失效。小菜一碟!

                      我开玩笑的,我开玩笑的,但说真的,现在你面临的是另一套问题。

          • 这是PHP世界中许多部署工具借助Git实现的方式。我认为它运行得如此顺畅,以至于没人会去思考其工作原理。

            • 这是一种完全合理的做法,只要你明白这是一项高风险操作,并能承受其后果,包括客户在浏览器中看到错误。如果这符合你的使用场景,那就继续吧!如果你无法接受这些后果,那么你必须切换到更复杂的升级系统,比如通过负载均衡器进行蓝绿部署等。换句话说,这就是Rust、Go、Python或Java应用的部署方法。

              • 从某种意义上说,这只是在文件系统级别进行的蓝绿部署?PHP通常运行在代理/Web服务器(现在主要是Nginx)之后。

                但你说得对,没有理由不能让两个PHP应用实例同时运行并切换。我使用过的PHP部署服务似乎都采用文件系统方法,我怀疑这并非懒惰或无能。

                • 我认为这是出于无知,我并非以刻薄或恶意的方式说这话。我听过很多PHP开发者抱怨说,与用其他语言编写的网站相比,PHP网站更新起来要容易得多,但我认为这主要是因为他们不理解其他语言推荐其他升级流程的真正原因。这些流程解决的是真实存在的问题,这些问题也影响着PHP,但它们被视为过度复杂、企业级或过于繁琐。

                  对于一个普通的网站来说,上述情况或许成立。如果你开发了一个每年访问量仅有1万次的个人项目,那就放手去做吧。它影响到其中一个用户的概率微乎其微,就算真的影响到了又怎样?但如果你在为一家大型公司托管一个流量巨大的Wordpress网站,那么理解为什么“直接用rsync同步文件”不是可接受的部署方法就至关重要。

                  • 抱歉,我们讨论的不是“用rsync同步文件”。我们讨论的是像Forge或Ploi这类服务的做法,即先将项目部署到独立文件夹,再切换符号链接。甚至可以回滚操作。

                    我感觉你是在嘲笑那些可怜的PHP开发者,但Forge是由创建Laravel的人开发的。我相信他们会仔细考虑过。或许,一个坏请求的微小概率并非那么糟糕。

                    • 这简直就是同一个问题,只是错误窗口稍微小一点。我并不认为那些开发者是愚蠢的,但我认为他们可能在生产环境中工作,那里对错误的容忍度比其他环境更高。

                      > 也许,也许,一个坏请求的微小可能性并不是那么糟糕。

                      如果贵公司能接受这一点,那真是太好了!继续这样做,然后解决其他问题。

                    • 我之前也想过这个问题,你这是在开玩笑吧。

                      如果你有非常长的数据库查询,然后在查询过程中使用蓝绿负载均衡器更新应用程序,你也会遇到同样的生产环境错误。这是同样的问题,只是由于PHP的特性允许这样做,因此实现方式略有不同。在不同的系统中,你必须使用不同的策略。

                      所以,是的,我们PHP开发人员有糟糕的部署策略,这让人感到不安。

                    • 那……完全错了。我鼓励你考虑为什么不会是这样。

                    • 这不是同一个问题,因为opcache的工作方式不同。在2025年,没有一个有能力的开发者会不使用opcache来运行PHP。

    • 比较对象应是同类语言:Python、Ruby、JavaScript。

      除了兄弟提到的无共享架构外:

      – 更成熟的开源包社区和生态系统,例如遵循semver等基础规范

      – 唯一明确的包管理方案,且该方案在同类中遥遥领先

      – 除可能与JavaScript相比外,整体性能更优

      尽管其他选项可能满足上述其中一项,但没有一个能同时满足全部三项。

    • 或许它能作为vibe编程的良好基础,因为已有大量相关代码?

      • 周围有很多糟糕的代码,我认为一个(良好的)静态类型系统的保护在这种情况下特别有用。如果有人做过这样的测试,我感兴趣阅读(但不感兴趣到自己去做)。

    • 坦白说,作者甚至没有很好地论证PHP自2009年以来有所改进。他的论点大多是“不要使用旧的、有问题的做法,现在有更好的方法了”。但如果你必须刻意记住不要使用旧的、有问题的做法,迟早你会自食其果。良好的默认设置很重要,而作者似乎忽略了这一点。

      • 我认为你低估了使用PHP语言默认设置和任何现代PHP框架默认设置时自掘坟墓的难度——这确实很难做到。

        我仍然认为PHP不适合绿地项目或其他任何场景,但他们确实很好地隐藏了所有潜在的陷阱。

        • > 我认为你低估了使用PHP语言默认设置和任何现代PHP框架默认设置时自掘坟墓的难度——这确实很难做到。

          同意。我记得在过去十年中愉快地启动了几个新的PHP项目,框架使用起来就像在任何其他编程语言中一样。

  6. 我使用PHP已有超过20年。它是我的后端首选语言。我不是服务器程序员,但PHP速度快、支持完善,而且如果你是个不错的程序员,可以用它编写健壮、安全、高性能的服务器。

    但我真的不喜欢这门语言。我从未对它产生好感。

    但我认为它仍将在未来五十年内作为主要后端语言存在。

    我觉得这张图表已经说明了一切:https://w3techs.com/technologies/history_overview/programmin

    我称它为“鱼缸图表”,原因显而易见。

    • 我好奇这张图表的数据来源。Scala 占比 4.6% 而 Python 仅 1.2% 的数据与我的预期不符,但我的行业认知可能完全偏离了实际。

      • 我好奇这张图表的数据来源

        他们显然开发了自己的网络爬虫,试图通过一系列未指定的启发式规则来推断网站使用的语言。我怀疑问题的一部分在于,判断网站是否使用PHP非常容易,而判断网站是否使用Python后端则困难得多,因此大多数使用Python的网站可能并未被统计在内。

      • 我认为我们往往会受到个人偏见的影响,这取决于我们的人际关系和职业文化背景。

        我完全相信这张图表,尤其是对于WordPress以及其他一些基础设施级别的工具而言。

        我知道色情行业仍然大量使用PHP。之前这里有一篇帖子,链接到一位PornHub程序员的发言,他谈到了他们的IT架构,而整个架构都是基于PHP的。

        它是一个无聊的劳动力。这种“无聊”的特质对IT专业人士来说反而具有吸引力。

      • > 网站的服务器端编程语言

        也许是因为大多数网站都是WordPress网站。

        • PHP的事情可信,但我仍然对Scala和Python感到困惑,这是基于我在行业中的观察以及参与这两种语言的招聘过程。也许是因为我从事B2B SAAS工作,这些产品并不总是直接暴露在公共互联网上。

      • 是的,这感觉有点不对劲,不过如果是在评估所有/大多数网站,那或许说得通,而不是评估按流量排名的 top N 网站。

        • 参见我关于成人产业的备注。

          这些网站的流量非常大。

          我确实注意到 JavaScript(可能包括 TypeScript)在上升,但 Java 也在上升,而且 Java 的排名仍高于 JavaScript。

    • 我已经使用它大约20年了。惊讶你还没有对它产生好感。它完全没问题。我仍然偶尔使用它来编写脚本,尽管我现在更喜欢TypeScript,因为它内置了一些不错的功能。

      • 我并不讨厌它,但我从未像对C++或Swift那样对它感到兴奋。

    • 我觉得那张图表只是显示了WordPress的 dominance(占所有网站的43%),以及一点Joomla(2%)和Drupal(1%),这些都是基于PHP的。

  7. 文章的冲击力因作者不断刻意强调“PHP反对者”是错误的,而非更好地解释PHP的潜在应用场景而减弱。

    我从未真正使用过它,但了解为何有人会在2025年选择这种语言进行绿地项目(考虑到现有选择)会有所帮助。文中给出的理由对我来说并不令人信服。

    • PHP开发人员容易找到且成本低于其他选择,仅此一点就足以让许多企业做出决定。

      • 我不会信任一个无法转行成为JavaScript开发人员的PHP开发人员。

        • ……而且他们相对便宜且容易找到?

          • 我常常希望情况并非如此。绝大多数JavaScript开发者与真正理解语言并掌握软件工艺的优秀JavaScript开发者之间,存在着如同大峡谷般巨大的鸿沟。这并不意味着要在基于JavaScript的项目中堆砌在所用平台上毫无意义的“企业级”模式。

          • 在疫情期间或之后开始从事JS开发的程序员比比皆是。拥有10年以上经验的JS开发者目前仅占市场的一小部分。而那些无论经验多少,都能真正理解JS(甚至只是计算机科学)的开发者,更是JS开发者中的极少数。

        • 通常 PHP 开发者具备 JavaScript 能力,但因 JavaScript 及其生态系统过于混乱而尽量避免使用。

        • 并非所有人都想成为 JavaScript 开发者。

        • 但我可以在大约两天内部署一个相当规模的Laravel应用程序……我需要学习JavaScript的等效实现。

  8. 我以一种有趣的方式爱上了PHP(现在回看我的职业生涯,这可能预示着我注定要从事现在的工作),因为它在大学期间救了我。

    在大四的倒数第二个学期,我不得不临时抱佛脚完成20个学分,因为我之前错过了某个要求。其中包括一个5学分的网页开发项目/讲座课程。我们的项目是构建一个电子商务网站。我们被介绍了几种构建端到端应用的范式,PHP是其中之一——正如其他评论者所指出的,我特别喜欢它的部署便捷性。

    然而,课程最后阶段却强迫大家转向原生JS,而我从未在使用它时取得过成功,坦白说我对它有些反感。我无法用它在学校服务器上部署网站——显然我不是唯一一个遇到这个问题的人。

    因此,我仔细查看了评分标准,发现其中只有20%是代码评估。剩下的部分是网站设计,而评分中最大的一块仅仅是按时完成部署。

    所以我用PHP编写了代码,因为我确信100%它能正常运行,而且我能按时完成部署。助教原本想让这个项目不及格,但由于代码部分只占20%的分数,我最终得了B-。几乎所有人都挂科了,因为只有少数人能成功部署。

    我非常想参与现代PHP项目,但不知道从何入手,也不知道外面有哪些项目,人们只是对它嗤之以鼻,因为它看起来丑陋不堪,而且有着安全漏洞的历史。

  9. 难道Corolla不是以功能和可靠性著称吗?这个类比似乎有些奇怪。

    • 我一直将Java比作语言生态系统中的本田思域,因此对PHP被称为“坚固、廉价且可靠的劳动力”的說法感到不满。

    • 功能可靠,但常被真正的汽车爱好者诟病为乏味且令人失望。

      当然,批评的具体方向并不完全相同,但其中确实有一个不错的类比。

      我对具体车型了解不多,但或许选择现代汽车作为PHP的恰当类比会更合适:曾经是一个可靠性问题较为普遍的品牌,但最近已经大大改善了这些问题,现在是一个非常可靠的选择。

    • 是的。我有一辆1990年的卡罗拉,那时候它是全球最畅销的车型,虽然设计简单,但功能可靠,设计也非常用心。

  10. PHP就像一辆德洛里安。我记得在一年内遇到了10次段错误,这简直是个笑话。这还是两年前的事。

    它还在点版本更新中引入了破坏性变更,这是一种毫无意义的维护策略——这与卡罗拉的稳定性声誉形成鲜明对比。

    尽管PHP可能有一些优势,但它在这一特定比较中立即失败。

    • > 我认为我在一年内遇到了10次段错误,这简直是个笑话。

      PHP中的段错误非常罕见。该语言确实存在一些缺陷,但它经过了极度严格的测试,通常在生产环境中不会崩溃,除非你使用了不稳定的扩展或预发布版本。

      > 它还包含在点发布中引入破坏性更改,这是一种毫无意义的维护策略

      有很多项目在发布时并不遵循semver规范;这并不意味着它们本身不稳定。不过,每个 PHP 版本至少都有完整的变更日志,因此你可以安全地迁移到新版本。

      • 是的,我记不清上次看到 PHP 段错误是什么时候了。我的一些客户仅使用 PHP 每月就能处理数十亿次请求。

    • 我绝不会认真考虑使用PHP。在2000年代中期,我曾以副业形式创办了一家应用托管公司。最初我托管FogBugz(缺陷跟踪工具),因为Fog Creek Software仅提供自托管版本。在接下来的9个月里我从未遇到任何问题——那是一款基于Microsoft ASP的应用(据我所记)。随后我决定托管一款名为HelpSpot的客服系统。当时那是一家一人创业公司,他也没有提供SaaS选项,所以他很乐意将客户介绍给我。软件本身没问题(而且至今仍在使用),但它是基于PHP的系统。无论我如何保持服务器更新,PHP服务器还是不断被黑客攻击,因为当时PHP对安全性的完全忽视。我的成就是我托管了Twitter的第一个客服系统。我厌倦了下班后几乎每周都要重建服务器,所以我以$2k的价格“出售”了这个初创的小副业。去他妈的PHP。

      • 虽然确实可能是PHP的问题,但当时大量低质量的PHP代码才是更常见的根源。

        这也是今天框架存在的主要原因之一。99%的开发者缺乏足够的安全意识,会在代码中留下巨大的漏洞。没有输入验证、SQL注入、未经验证就信任代码中提交的数据,等等。

        如果你在不断被黑客攻击,无论如何更新,很可能是代码本身有问题,而不是PHP。当然,你的服务器可能已经被植入了后门。

        框架通常能防范这些问题。

        • 抱歉,我不认同,当时从安全角度来看,PHP简直是一团糟:

          https://www.cvedetails.com/vulnerability-list/vendor_id-74/P

          https://www.cvedetails.com/vulnerability-list/vendor_id-74/P

          • 当然,你的经历很糟糕。但我们不妨继续对一种基于20年前错误的编程语言嗤之以鼻。

            • 我对PHP还有很多其他问题,这些问题在过去20年里都没有得到解决。市面上还有很多更好的工具。你不必选择它们,我也不必选择PHP。

              • 当然,你不需要。

                但当你能够实际列举的问题都是20年前的,且基于某个特定实现,而非PHP作为一门语言本身时,这并不反映PHP的缺陷。这反映了你的批判性思维能力——或者说,至少反映了你说服力不足。

                • 我无需列举PHP的所有缺点来证明我的立场。

                  • 没人要求你这么做。

                    但你称它为“垃圾”,声称你——个人——除了你特别提到的陈年旧事外,还有“其他很多问题”,却不做详细说明,还期望我们仅凭你的话就相信。

                    你要求我们重视你对它的低评价,但你没有给我们任何合理的理由。

                    • 听着,没关系——你们喜欢PHP,我确信它有一些优点。我对它的看法依然如故。就像我无法改变很多人对C#/.NET的看法,因为它来自Micro$oft。我们可以同意不同意。

  11. 坚决不同意。PHP是编程界的福特Escort(需要定期维护,安全性较低,但易于驾驶和控制)。不像丰田卡罗拉,它真的非常可靠、稳定且安全得多。

    (作为一个多年来维护过多种车辆和编程语言的人,这甚至不够格。PHP是一辆问题车。)

  12. 我认为作者指的是编程界的日产Versa。卡罗拉要贵得多,保值时间也更长。但两者都非常有用。

    我用shell脚本编写的代码比其他任何语言都多,这已经持续了近十年。原因很简单:我不是在编写网页应用。我主要从事系统编程(即构建或维护系统所需的任务,或一般以用户为中心但非交互式的任务)。对于大多数此类任务,一个shell脚本就足够了。

    我的同龄人当然会对 shell 脚本嗤之以鼻。如果不是使用更“高级的语言”,那它一定不可靠、难以维护或丑陋。然而,多年使用多种语言编写程序的实践经验让我得出相同的结论:任何语言都可以。你可以用 BASIC 进行系统编程。你可以用汇编语言。它会工作。人们会争论一种语言是否“更好”于另一种,但谁在乎它是否更好?如果它能工作,那就行。但这是因为几乎任何语言都能用于那种类型的程序。其他类型的程序需要高级功能,所以你需要更高级的语言。但对于简单任务?无所谓。

    回到汽车的比喻:你可以用任何一辆车去买杂货。你不能用任何一辆车去搬运3000磅的沙袋。

    如果我们是科学家而非工匠,这些讨论都无关紧要。我们会选择专为特定目的设计的工具,而非纠结于个人偏好或理想主义原则。但我们的语言,以及使用它们的方式,远非科学。我们不过是一群工匠在水冷却器旁闲聊。

  13. 在使用了许多“丰田卡罗拉”来构建网络应用程序后,是否有人在2025年感到一丝挫败感,因为团队有机会在客户端和服务器端都使用TypeScript,却选择不使用?

    “使用我熟悉的另一种语言来处理后端,它是[可靠的汽车型号]。它是编程世界的{拉丁语、斯瓦希里语、英语}。它是JVM,它是PHP,它是Python,它是Ruby,它是C#。”

    我认为,经过十年的系统切换,TypeScript现在已经成为“足够好”的语言。我们必须在客户端使用它。现在我们也可以在服务器端使用它。

    2010年代那些怪异的Node.js库项目,到了2020年代已成熟为完全支持的生产系统。

    我从未如此开心。它是个不错的后端选择,前端也几乎不可或缺。这很重要:就像通用语言一样,TS/JS在网页应用中不可或缺。这是PHP不具备的属性。

    • 据我所知,仍有一些后端开发者关注性能问题

      • PHP的性能更优?这让我感到意外,毕竟V8引擎投入了大量开发资源

        • PHP 表现尚可——如果启用了 Opcache 并正确配置,它就能胜任任务。不过我还没尝试过最新的 JIT 功能。

        • 根据我的个人经验,PHP 的性能要好得多,即使在切换到 Frankenphp 之前也是如此——Frankenphp 比 Express 好得多,这可不是开玩笑。

          当项目规模变大时,PHP 更易于阅读和处理。而且更安全,因为你无需依赖所有这些 NPM 包(我们使用 Composer,但与使用 NPM 的方式截然不同。PHP 几乎内置了你所需的一切——即使使用 Laravel,它也不是金字塔结构)。

          我已经阅读了所有评论,但我真的不明白——我大量使用 Node 和 PHP,也用过不少 Python。对 Go 或 Rust 的经验不多,但对 Java 有一些了解。

          依我之见,在速度、安全性(至少在网页开发方面)或网页编写易用性方面,没有其他语言能与 PHP 匹敌。

        • 可行的替代方案不是PHP,而是几乎任何合理的编译型语言。

    • 我对TypeScript(以及Node/JS)在后端的主要不满是,它很难实现水平扩展。你启动Node时,它只是一个单一的事件循环。

      大多数人会建议你使用pm2来启动服务器的副本。然而,pm2看起来像是拼凑而成的临时解决方案。而且pm2与他们的付费pm2服务器存在利益冲突。这使得他们有动力限制pm2的免费版本功能。

      其他人会建议你使用多个Docker容器。对于某些应用程序来说,这似乎有些过度。

      为什么不能有一个简单、成熟、内置的多线程服务器,就像.NET Kestrel或Go HTTP一样?

    • 目前尚不清楚 TypeScript 是否拥有与之相当的后端生态系统。对于 JVM,你可以找到可靠的、某种程度上文档齐全的、广泛使用的库来处理大多数后端需求:数据库驱动程序、支持特定安全协议的 SOAP-XML 库(用于与某些金融/医疗保健机构的 API 集成)、日志记录、监控等。

    • 但你會失去這些其他語言的簡潔性。例如不需要複雜的建置設定,也不需要依賴不可靠的依賴項。與 Django、Ruby on Rails 和 Laravel 相比,JavaScript 沒有如此功能完備的解決方案。

  14. Corolla 雖然簡單,但設計非常出色;其手冊甚至被用於教授汽車維修的課程。

    PHP 设计不佳。学习编程的人不应将其作为第一门语言。人们选择它的原因在于它免费、比 Perl 更简单,且在共享主机时代部署成本低廉。

    你最好从类型化语言入手,如 C#/Java/Kotlin(面向对象优先)或 OCaml/F#(函数式优先),甚至 Golang。

    若将PHP作为第一门语言,会阻碍你的学习进程。

    • 它教会你以简单直接的方式完成任务的价值。我与一些从小使用Java的人合作,这点很明显。他们倾向于过度复杂化一切。

    • 老兄,你说得对极了。Common Lisp 就是编程界的 Bagger 288。这台机器堪称绝对的巨无霸,设计初衷就是为了吞噬山脉。当第一座矿井关闭时,它并未退役或锈蚀报废。人们以每小时 2 英里的速度将其开往德国,沿途搬迁村庄并夷平一切障碍。人们纷纷出来观看它缓缓驶过,仿佛它是一尊钢铁神明。最终它在另一座矿场找到了新工作,继续完成其他机器无法触及的任务。

      这就是Lisp。它在人工智能流行之前就被设计来解决脑级问题。它并未消失,只是在世界其他地方堆砌一层又一层框架和炒作时,它始终在做自己的事。它不时尚。它没死。它只是太强大了,以至于大多数人甚至不知道该如何使用它。它不会为你编写待办事项应用,但如果你试图构建一些真正需要思考的疯狂东西,Lisp仍然在那里,等待着。

  15. 我使用PHP编程已有至少25年。虽然PHP最初在安全性方面设计得相当糟糕,但PHP的新版本以及PHP框架如Laravel、Yii等在过去几年中已变得相当成熟,是Rails等框架的绝佳替代品。

    内容管理系统(CMS)框架也得到了显著改进。

    PHP 的改进包括性能的大幅提升——PHP 7 相较于 PHP 5 有了巨大进步,而 PHP 8 还引入了 JIT 编译器,语言本身也进行了优化,如类型系统、面向对象支持、改进的错误处理等。

    PHP 8 的运行速度比 Python 快约 3 倍。

    https://sailingbyte.com/blog/php5-to-php8-modern-programming

  16. 我一直对 Hack 感兴趣。它基本上是 PHP 逐步演变为更接近 Java 的语言(Java 并没有新毕业生所说的那么糟糕,与 PHP 相比,它实际上非常出色)。它几乎专用于 Meta。

    基本上,他们所做的是通过反复的代码重构(使用自动化工具对整个代码库进行修改),逐步将PHP向Java靠拢。逐渐引入了更多的静态类型、泛型,以及Java中常见的抽象数据类型(ADTs,如Vector、Map、Set、Pair等),还采用了字节码+即时编译(JIT)执行等技术。

    本质上,他们没有将代码库重写为更好的语言,而是直接改变了语言本身。这有其合理性,因为PHP的代码库远小于Meta的后端。

    • 我几年前(几乎10年了?)曾尝试过Hack和HHVM,但之后就没有继续关注了。我理解的是,PHP8+现在已经包含了Hack带来的改进,使得转向Hack的吸引力/价值降低。情况不是这样吗?

      • PHP在性能上赶上了Hack,但它仍然缺乏许多Hack的特性,尤其是泛型和异步/等待。

  17. 我对文章未提及Laravel感到惊讶。

    作为语言,PHP确实有所改进但仍不理想。不支持异步,标准库糟糕,数据结构极为简陋(无元组、无列表、无映射,仅有一种混合了映射和列表的奇怪数组类型),旧扩展系统也令人失望。

    但生态系统?天啊。我看到很多人说TypeScript是后端开发成熟的选择。说实话,我原本想相信这一点,但我不同意。使用Laravel的开发效率简直令人难以置信。你所需的一切都已内置,你可以以几乎不可思议的速度启动项目。

    TypeScript没有这种优势。也许是因为这个生态系统中的不同心态(你应该自己构建模块),但没有其他框架能与之匹敌。最接近的可能是Adonisjs,但它似乎没有获得足够的关注。

    你不会选择一种语言来构建你的网络项目。你选择的是技术栈。一个框架。我个人更倾向于 Python,但 Django 的功能远不及 Laravel,而且我并不享受使用它的过程。后端使用 TypeScript 本是我曾寄予厚望的(因为前端与后端共享类型是个绝佳想法),但感觉自己不得不重新发明轮子,或者至少要选择 20 种不同的轮子来完成一个相当简单的事情。

    Ruby 真的是一门伟大的语言,还是人们只是喜欢用 Rails 提高效率?在我看来,不使用 Rails 的 Ruby 应用似乎很少(我可能错了)。

    人们选择并坚持使用技术栈,而不仅仅是语言。我找不到与 Laravel 相当的替代方案。如果能给我一个同样高效的技术栈,我愿意放弃 PHP。

    • 我现在的日常工作主要是Python和Vue,但PHP是我近20年的主要收入来源,至今可能仍是我的最爱之一,仅仅是因为我对它非常熟悉。了解所有陷阱和棘手之处,并知道如何避免它们,这确实有其价值。

      在早期支撑 PHP 的因素,尤其是其部署的极简性,到了 2025 年已不再像 2005 年那样重要。共享主机虽然仍然存在,但已逐渐成为过时的模式。如今我看到的绝大多数现代PHP开发项目,都是基于nginx/PHP-FPM和容器的架构,这与其他Web框架的差异其实并不算太大。就连WordPress,我如今也建议任何真正想走这条路的人,直接选择托管的WordPress服务商,而非自行搭建。

      个人而言?我绝不会现在用纯PHP启动一个全新项目。我认识的人中也没多少会这么做。

      但PHP + Composer + Laravel?Laravel之于PHP,就像Rails之于Ruby,以及React/Vue等之于JS。Composer为PHP带来了真正的包管理。拥有一个框架和包管理器来处理所有那些令人讨厌的部分,其重要性无法被低估。这样你就可以专注于构建应用程序,而不是重复实现那些你已经做过无数次的事情。

  18. 我很少遇到比PHP更让我反感的编程环境。是的,它能完成任务。但感谢上帝,我从未需要维护那个用胶带和橡皮筋拼凑而成的庞大烂摊子。

  19. “氛围编程”也是编程界的丰田花冠,亚当花冠

    https://www.youtube.com/watch?v=iNMrQUF6Fvc

  20. 完全同意。

    我曾指导过许多PHP GSoC项目。我总是要求学生使用90年代末或21世纪初的PHP二进制文件(我认为这是最佳选择)。这些版本通常在设计和实现上更为简单,经久耐用,而且——对于你发现的相对较小的错误——你可以在网上找到大量解决方法。

    我确实理解人们选择最新版本的便利性。但这些GSoC学生通常参与的项目涉及个人健康数据等敏感信息,必须确保这些数据在面向公众的服务器上得到安全保护。对于这类场景,能够理解引擎的工作原理——甚至在必要时手动更换引擎——对保障安全至关重要。

    简而言之,这些早期版本是由工程师设计来“持久使用”的。如果你知道如何修补运行时,你基本上可以让它们永远运行。

    然后……场景。 🙂

    • 你怎么保持它们的安全?

      “场景”的意义是什么?

  21. 即使在多年没有用PHP构建任何重要项目后,它在我心中仍占有一席之地。我记得大约15年前编写PHP代码时那种高效的感觉。我认为自己可以用它做任何事情。然后Laravel框架出现,使这种体验至少提升了一个数量级。

    我认为PHP当前面临的主要问题在于,它过去曾存在诸多问题(尤其是安全方面),导致许多人认为今天的PHP仍是过去的PHP,而实际上它已演变为一个功能强大的编程语言/环境,具备相当不错的特性。似乎无论PHP社区如何努力,都无法摆脱这一刻板印象。

  22. Corolla的设计非常出色,其主要目的是成为该细分市场中的现金牛。PHP只是能用,但设计并不出色。它之所以相对容易部署,是因为每个人都不得不学习如何部署它——与部署Go二进制文件相比,这简直是痛苦的。

  23. 我花了几年时间尝试维护遗留的PHP系统。如果我有选择的话,我绝不会再接受任何使用PHP的项目。大多数大型科技公司没有庞大的PHP代码库,而大多数小型临时PHP代码库在我的经验中都难以维护,因此“使用PHP”与“更高质量的软件工程”的交集非常小。我不会说这是一个空集,但这是一个很小的机会空间。与此同时,不得不处理真正糟糕的代码库的概率是……很高的。

    总的来说——我们生活在一个拥有众多出色编程语言的世界中,所以我如果能选择的话,绝不会为一个绿地项目选择PHP,也不会追求涉及遗留PHP代码库的专业机会,除非在非常特殊的情况下。

  24. 那些不从事内容网站工作的人可能不知道,在前10名最佳内容管理系统(CMS)中,有7个是用PHP编写的。我甚至不是指WordPress。而是像Craft、Kirby、Twill、October、Bolt、Statamic、Bookstack、Dokuwiki、Mediawiki等。用JavaScript开发的CMS虽然也有一些不错的,但它们缺乏功能和成熟度。

    这就是为什么它在那些圈子里如此受欢迎。如果你想要一个真正可靠的自托管平台用于发布/电子商务,你无法避免它。

    对于单页应用程序(SPA)或任何实时应用程序……当然可能有更好的选择。但许多机构在开发人员已经熟悉PHP的情况下转向制作小型应用程序,这并不是一个糟糕的选择。

  25. 2024年,我曾问过“Raku能否取代PHP?”

    https://rakujourney.wordpress.com/2024/09/15/can-raku-replac

    如果你在想,Raku可以直接替换PHP……

      “PHP”.subst(/PHP/, ‘Raku’).say;    #Raku
    

    但这并不是重点。只是我觉得-Ofun有点过头了。

  26. 抱歉,这对于丰田和卡罗拉来说是一种侮辱。PHP顶多算是一辆日产汽车。

  27. 卡罗拉可能很无聊,但它是那种设计精良的无聊。我认为Python或Java才是编程界的卡罗拉。

    PHP既无聊又设计糟糕。也许更像一些非常老旧的东欧汽车。

  28. 人们忽视了人类因素在塑造卡罗拉在人们心中的形象中所起的作用,这令人失望,尽管完全可以预料。

    如果“天籁车主”历史上大量购买卡罗拉,卡罗拉就不会是你们想象中的样子。许多人应该思考其他产品类别中类似的影响(Adobe Flash 就是个例子)。

  29. 我认为这个类比不成立。卡罗拉受欢迎是因为它们是好车。人们做出购买决策是基于个人选择,且长期来看通常对这一选择感到满意。卡罗拉并非令人后悔的产品选择。

    PHP更像是一辆Lime滑板车。初始使用极为简单,启动迅速,但存在造成脑损伤的显著风险。

  30. 如果PHP是卡罗拉,那么我20年前的PHP应用程序今天无需修改就能运行。但事实并非如此。

  31. 编程界的特拉班特

  32. 从评论中可以看出,这篇文章实际上是在讨论汽车。

  33. 我认为JavaScript的魅力在于,你可以利用有限的服务器资源,让软件主要在客户端运行。

    我对使用PHP持保留态度,因为我真的不想占用大量服务器资源,但如果我正在开发一个需要大量服务器资源的应用程序,我也会考虑使用PHP。

    • 这确实是JavaScript的一大吸引力,但也要考虑客户端是浏览器这一事实,这意味着你可以让JavaScript在无数设备上运行。自Node.js推出以来,使用一种语言同时编写服务器端和客户端代码的吸引力也日益增强。

  34. 我认为WordPress对PHP的成功产生了重大影响。它被用于40%以上的网站。它以一种允许人们修改实际代码(或至少查看代码)的方式进行设置。主机提供商必须确保PHP预装且可用。

  35. 在我转行之前,我作为PHP开发者赚了很多钱。

    在我20年的职业生涯中,我从未失业过,而且一直有很多工作机会。

    我认识的许多使用其他语言的人在过去几年中遇到了更多困难。

  36. 我仍然认为将PHP与HTML混合使用是最好的方式。不是PHP+Jinja,就是纯PHP。

  37. PHP虽然无聊但管用。我惊讶于HN上关于PHP的职位不多。我并不认为自己是PHP程序员,只是我们使用它时,几乎从不深思。

  38. 每当我在HN上看到关于PHP的讨论,就会联想到Gell-Mann遗忘效应。与其他话题相比(我猜是人们对其他话题的讨论水平更高?),关于PHP的讨论水平简直糟糕透顶。

    有趣的是,社区中80%的开发者显然对现代PHP一无所知。人们提到共享主机、HTML文件中的代码、CGI和糟糕的安全默认设置。需要明确的是,这些东西在PHP世界中已经死亡超过10年,但这里的大多数开发者只在2005年使用过一次,从未见过它在现代生态系统中的样子。

    这就像每次讨论Java时,讨论只围绕使用Java 1.8的开发者展开。

    很可能,HN上的其他讨论也处于相同水平,但我更难发现其中的错误。

  39. 如果PHP是丰田花冠,那陆地巡洋舰是什么?Rust?

  40. 我不同意,抱歉。显然是Java。

  41. Clojure是编程界的奔驰。

  42. 那么编程界的凯美瑞是什么?

  43. 没错,我认为这触及了“评判编程语言”的最大问题。

    我们希望“理论上的根本美学能强烈预测出美丽且有用的程序”成为评判语言的标准,但事实是,这从未实现。

    直到人们开始用它来创建东西,这些才重要。而人们用这种语言创建东西,进而吸引更多人用它创建东西,才是_首要_指标。

  44. 那Java是什么?

    • Java是一种用于将大型XML文件转换为堆栈跟踪的领域特定语言(DSL)。

    • 一辆由大众甲壳虫改装而成的苏联移动城堡

      e:(我唯一真正的Java经验是Spring Boot)

    • 看看Java安装程序:什么是Java?Java无处不在!

    • 一辆丰田卡罗拉,你每天都要导入1000个名字冗长的部件才能让它运行。

      • 即使在我还没接触Scala的时候,我也用IDE完全自动化了这个过程。这是系统中最不烦人的部分。

    • 一辆被大型农场使用的约翰迪尔拖拉机。

  45. 如果我是丰田,我会起诉。

  46. [删除]

  47. PHP 必须死亡,这不是一个愿望,而是一种执行范式。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

链接收藏


京ICP备12002735号