为什么程序员鄙视python_为什么有些程序员看不起 PHP 这门语言？

觉得有必要补充一点，首先，我个人打心底没有看不起 PHP；工作中我还算能镇得住场子，身边没人明确表现出看不起。但我认为 PHP 可能会被很多人看不起，原因不在于它做什么和怎么做的问题，而在于“规矩”二字。老马继续苦笑：“跟你讲个故事。狗栏里关了五条狗，四条狗沿着顺时针方向跑圈，一条狗沿着逆时针方向跑圈。后来顺着跑的四条都有了人家，逆着跑的那条被宰了吃肉，因为逆着跑那条不合群养不熟，四条狗……甭管怎么说，它们的价值也是一条狗乘以四——你听明白了吗？

。。。。。。

许三多不理他，接着说他的“明白”——那条狗要是一会儿顺着跑，一会儿逆着跑就好了。

老马明显是噎了一下：“为……什么？”

“因为……反正在圈里，反正得跑圈，这样有意思一点……”许三多被老马瞪得有些发毛，顺时针逆时针地划着手指，“这样跑不容易晕……跑圈嘛，很容易晕的。”

我觉得用《士兵突击》这段来评价 PHP 非常的恰当。以下为原回答(有整理)：

开始学了些 Java，根本就不会 PHP，为了糊口乱投简历得到一个机会，看了一晚手册瞎蒙到一个 PHP 的岗位，从此就写了十几年。

说缺乏企业级功能这个是不太妥当的，RPC/SOAP/WebService 这一整个体系从表到里都是很完备的，而且十几年前就是官方标配的。刚工作那会儿因为了解得不够，我还直接用 Socket 通过 WS 连接过另一个 C# 写的大/中型系统，包括解析 WSDL 等一系列标准化的东西，整个过程写得还是挺开心的，就是当时觉得 Socket 的速度不咋地。做爬虫也没啥问题，通常不太关注性能时一个 file_get_content 能解决不少事，配合内置的 DOM/Xpath 组件还是挺轻松的；当然了，也有别人封装好的，开箱即用。至于线程、连接池什么的，印象里好像没操过心，因为大部分时候就是当胶水语言用，也犯不着干什么特别的活。

要说优点，我觉得就是处理字符串很简单，很多年前还写过 Perl，那是我认为对字符串最亲和的语言，但是 Perl 总是要区分标量、数组、哈希，尤其是那个引用规则，加上她 OOP 里那些个宗教用语，显然 PHP 相对来说规则要简单太多。而 HTTP/WEB 也就是一堆字符串来回折腾，个人觉得只要方便处理字符串的语言，都天然的方便处理 HTTP 相关的东西——所以，3P 都适合。

瞧不起？这倒谈不上，我自己至今还得写 PHP 呢，但以下观点可能是现在程序员瞧不起 PHP 的原因的一部分：

首先，如果你只用过 PHP，或者在教科书上学过 C 并还写过几行，那应该还没到”看不起“的状态，上面说到的处理字符(串)相关的大部分函数，二者之间太像了，PHP 简直就是一个 C 的 Shell 版本，写完就可以执行，还是很有意思的。但是，这些 PHP 早期(我最早也就用 PHP 3.1 再往前没考究过)就带着的基础函数有个大毛病，命名规则不统一加上参数顺序稀里糊涂，很多程序员都有对齐、命名强迫症，会觉得这设计得也太随意了。如果你按用途和添加时间分个类，就会发现也没那么糟了。

其次，神奇的 array，老实说我觉得这也许算个优点，搞得我甚至在 Java 里都习惯一个 Map 通吃全部结构，并弄了个方法集以便像 PHP 的 array 一样随意多层存取而不报异常(Dict.java)。这个观点估计会被喷，没错，这就是我要说问题之一。对于一个已经习惯了在其他语言里区分数组、哈希等的程序员来说，这 array 是个啥玩意呀，它同时是 list/map/set，那么你的同事写的代码传递给你一个 array 时你也得小心了，两人没讲清楚结构最终可能就要干一架。我亲眼见我以前一位组员因为 array 转 JSON 与前端争得面红耳赤，就因为在一个数组里混入了一个字符串的键值(几层后删掉了)，导致前端收到的数据时而是 array、时而是数字下标的 object。

再之，因为有人拼 SQL 、路径或命令时直接把变量拼进去，在 PHP 里这超级方便，而这个变量很可能来自外部请求的参数，这导致到处都是可注入的漏洞(注意：不仅仅是 SQL 注入)。 早期不知道哪个倒霉催的出的馊主意，搞出 magic_quotes_gpc 这么个垃圾玩意——倒是对得起这么魔幻的名字，导致你在某些框架里还得考虑这玩意是开了还是关了，你要转义还是不转义(可能导致转义两次)。这特么就是出了问题你不让人把问题解决，却特么瞎琢磨还说都是为你好，你咋知道我写程序就一定是读写数据库呢？你咋知道我对送来的字符串就不作切割或转换了呢？好多好多年了还得去补不知道何方神圣挖的坑。

然后，错误处理。总的来说他有三套异常方案，返回值、error_handle、try/catch。返回值本来没什么好说的，但问题是一般比较时 void、null、false、0、空数组、空字串和字串0 均表示否，尤其是那个字符串0简直是新手犯错的重灾区。error_handle 的问题在于截获的现场不在当下，什么意思呢？当 trigger_error 后仅仅表示程序有问题、或有要注意的事，在发生的位置，你可以终止也可以继续，所以这根本不像一种异常处理机制，倒更像一个试图统一的运行时日志机制。多说一点，过去我自己写的 PHP 框架初期也对 error_handle 存在误区，认为只要通过错误等级或代号，在回调函数内作终止和忽略(记日志)即可；但通过实践证明这个想法是极不成熟的，你编写时认为的“错误”也可能在实际某个过程中只算“异常”，可以挽救或仅仅只是一次尝试。

还有，全局环境。比如 $_GET、$_POST 直至 $GLOBALS，它太方便(没规矩)了，导致程序员虽然从表面上分了 MVC，可是不知道哪层突然想用到一个比如 Session 里的什么东西，就直接取了——手册就这么教的。开了这个口子，那怎么改需求、改 Bug 呢？到处加“飞线”呗，用不着一层层的折腾，改起来那叫一个痛快。你看到一个模型类的方法的参数是 3 个，但他可能莫名其妙的因为需求变更而内部通过全局又用了一个外部变量，那么就可能导致另一处调用此函数的地方并不知道内部还有这么一出戏，而在不确定的某一天爆发。这个问题你说其他语言会不会？当然也会了，Java 也有 ThreadLocal 呀，但是并没有成批的养成这个习惯，培训的人也不会告诉你还能这么干(使用一般 static 属性做飞线传值会因多线程环境而产生问题)。应该重构和贯彻 UnitTest？那说好的开发快、好上手的特点就要失去大半了。至于调试，输出就行了、断点是何物？真的碰到认为 echo + exit 就是 breakpoint 的。

头两个对我来说还不算毛病，甚至我还认为写代码的稍微注意点就可以算优点了。说说我最不爽的。作为胶水语言 PHP 挺好，但问题在于早期也就仅限于能做胶水。过去 PECL/PEAR 收录的还不是很全，或者倒霉催的遇到前同事遗留的不知道啥法子编译安装的 PHP 时，你想加模块也得跟着编译。这一编译不打紧，在 Linux 上有非常大的概率遇到依赖问题，一个库要这个版本，另一个库要另一个版本，或者依赖的库又依赖另一个库。当你在你自己的机器上搞得一切顺利的时候，结果上了客户的机器就一箩筐的问题，搞得下不来台。

后来都用 PECL/PEAR 安装附加组件这个情况就好转了很多，但还有些依然是他定位为胶水语言带来的问题。要个消息管道，要安装额外的服务；要个搜索引擎，要安装额外的服务；要个状态共享，要安装额外的服务……你当然也可以说，微架构嘛，现在流行呀；以前这个概念可还没成体系，那得等到有容器概念了这么玩才说的过去，演示时就一台机器一个系统，没准里面装了些可能冲突的东西，在上面编译完这个编译那个，头都要整麻木了。用 Java，数据库用 SQLite 内置，HTTP 用 Jetty 内置，Web Socket 内置，搜索引擎内置，消息队列内置，计划任务内置……要演示就把 JDK 一块打包进去，写好启动脚本，双击运行。我也就服务些小客户，大部分时候这就够了，一般也就换下数据库；要有不够用的，打钱，接口我都留着呢，我给您换成微服务架构。

当然你可能会说那你可以用 Swoole，看过几回但没用过，我觉得这完全是个新东西，甚至不在 PHP 语言的讨论范围内。这几年我写 PHP 写得少了，PHP 自身进化也不小，也肯定有些更新覆盖到我上面说的内容的。但是，你用 PHP 就不可避免的要碰到旧的代码、旧的架构、旧的系统，那些令人不快的东西就一定会碰到——先入(PHP)为主除外。

写得还挺嗨，再补充点，还有我觉得 Python 也不爽，尽管他挺适合我这个对齐强迫症重度患者。我觉得所有容易修改的脚本类语言在做规模较大的东西时都不爽(注意：我没说不能)，那个”反正很容易改嘛你就写死呗“的魔咒会一直围绕着你和你的同事，跑也跑不掉，也一定会导致总是事前欠缺思考(总结)，事后瞎几把折腾。

有时候你也不能批评这个语言不好，因为它只是多做了些封装、多提供了一些可能，这有错吗？你更不能批评人不行，在不同的历史时机使用她的人群也不尽相同。语言是什么？语言就是交流的规则。但愿随新老交替，能贯彻好规范吧。

^____^ 我是个老码农，热衷于造轮子，别学我。