@gouchaoer 不停地尝试并不能解决问题。
这种尝试的代价是很大的。（比如 Python 是最好的两个语言？）

比如说写个程序，你可以尝试，因为大不了 git checkout HEAD~1。
但是语言的尝试是永久生效的，而且一旦要 revert 必然要被人围殴（程：MMP 怎么又不向后兼容了？）
这里 +和. 的占用直接导致了难看的反斜杠语法。
其实还不止这一处。想想 :: 和 -> 之分？

$deletedRows = App\Flight::where('active', 0)->delete();

哇塞我的氪金狗眼……

@zzuyanan DLE = Datalife Engine
哪里有定制？我也不知道。把预算和定制需求报出去问问看咯。

600 万文章用 WP 你不定制的话这配置我觉得跑不动。
隔壁有个 60 万文章的用 DLE （号称比 WP 快？）独服都跑不动，老老实实定制完，双核 VPS 就能随便跑了。

@gouchaoer 虽然你说的我们都懂，但是有时候还是会说一句……

「这代码真™难看啊！」

就像你拍 Cosplay，拍一个美少女 JK 和拍个 Feng 姐，你选哪个？

何况说 PHP 实用的我也要打个问号，实用性和别的语言比能高到哪里去。

#↑ @jfcherng 如果一定一定要找个原因的话，那就是 PHP 最开始并没有面向对象的概念。

@noli 顺便提一句，AVX 2 从内存中载入也是要边界对齐的，否则影响性能。
虽然实际并不会有多大的数据量导致这么显著的性能差异就是了。

@jlsk 你说的没错，3 字节做不到内存对齐，不利于 CPU 处理。

至于你的发言，我只能说，v2 喷子已经有很多了，阁下一口一个傻逼，还请右转百度贴吧。
v2 不缺喷子，不需要阁下的加入。

已露怯。

好像还行，我这丝丝换了口以后好像 IP 没事。

345.78 不是一个有限位数的小数，因此不可能在有限存储空间里直接存储这个数的精确值。
一个近似结果是 345.779999999999972715158946812152862548828125。
乘上 100 以后取整，34577 的结果并不算意外。

pry(main)> '%f' % a
=> "345.780000"
pry(main)> '%.10f' % a
=> "345.7800000000"
pry(main)> '%.15f' % a
=> "345.779999999999973"
pry(main)> '%.45f' % a
=> "345.779999999999972715158946812152862548828125000"

@janxin 基于 cgroup 管理子进程。停服务的时候直接子子孙孙统统抓起来杀掉……

首先，LTS 内核版本就是原生内核上打补丁，一回事。
其次，内核自家的补丁维护者有时候就是 Ubuntu 或者 Debian 的 Kernel Team，他们自己知道哪些补丁重要，哪些不重要。
最后，既然是 stable，就不可能这么频繁地更新，还是要先走测试流程再导入软件源的。

@esolve 抱歉我没说清楚。我的意思是被封了完全正常。

你知道为什么 PHP 那么多东西都莫名其妙用的 Warning Error Fatal 而不是异常吗？



因为 PHP 初期根本就没异常这东西……

类和对象在 PHP 4.x 就有了，而异常呢？ PHP 5 才有。

所以这也不能算是最辣鸡的地方，因为异常是语言特性，而 PHP 才刚刚支持没多久。
在语言逐渐发展过程中，会慢慢修正原先的设计路线，加入新特性的。

@geeglo A-Za-z0-9/= 一共就 64 个字符，外层一看就知道是 base64。

@XiLemon 2017 年 9 月的版本，然后被微软拖延症拖到 10 月才发布。

@fatduo city = city 的子查询目测很难用上索引。

@nestlake 这种需求我不会考虑在 SQL 上做。

这种 SQL，怎么说呢。
写的时候一时爽，跑起来了○○○。
数据量小也就算了。数据量大的话真不怕后人提着刀来算账吗……嚯嚯

顺便提一句……现在不是 2010 年 97 月。

@onlyhot 有啊，合同上写明就行。