@liuxu 那不妨把你想表达的意思以更直接（也就是更“傻瓜友好”）的表达表达出来？

我个人的理解，你的意思是楼主对 PHP 的抱怨，是对 PHP 团队工作的不尊重。
我的意思是，PHP （实现）团队在优化方面尽力了，但是无力改变 PHP 语言本身设计的一些问题。用极端点的话说就是，路线错了，知识越多越反动。
楼主也并没有抱怨 PHP 有性能问题，只是觉得 PHP 不适合自己而已。

我没学过 PHP，但是我说一点我的观察：楼主所谓的“设计之初就留下的坑”，很大程度上是设计者最开始的动机就有问题。

根据 PHP 的维基百科页面所述 https://en.wikipedia.org/wiki/PHP：
“Early PHP was not intended to be a new programming language, and grew organically, with Lerdorf noting in retrospect: 'I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.'"

可见 PHP 的设计者最开始并不知道该怎样设计编程语言，甚至本来就没想设计一个好语言出来，仅仅是为了满足自己手头的需求。
当然，就算一个人对“设计语言”这件事真正上心，想做一个好语言，而不仅仅是一个短期好用的工具，这个人本身也要有足够的水平。
这两点是一个好语言的最基本前提。PHP 在第一点上摔了，Go 貌似在第二点上摔了。

https://zhuanlan.zhihu.com/p/66349646

我给楼主支个小招，楼主买了这么多手机，每一台都是为了什么买的？这样的理由充足么？

比如就楼主在贴子里列出的几点而言：
某手机”不断刷机的快感“——好像用模拟器也可以，刷起来还更方便
某手机”近原生的 Android“——这个模拟器也可以，并且既然上面某手机已经可以”不断刷机“了，刷个原生 Android 应该也可以
某手机"拟物界面"——好像模拟器也可以 ... 并且既然上面某手机已经可以”不断刷机“了，刷个拟物界面应该也可以
某手机”超薄“——如果仅仅是超薄的话，过两年降价或者超薄普及了会更合适

如何做得更好呢？
我个人的选择是搭摩尔定律的 便 车 ，将自己的”体验“流水线化，简单来说是不追新，甚至有意避免”新“的东西。
这里我首先进行了自我教育——一个东西的好坏和其时间没有直接关系： https://en.wikipedia.org/wiki/Appeal_to_novelty https://en.wikipedia.org/wiki/Chronological_snobbery
此外我在技术上的经历让非常深刻地体会到一个东西的好坏和别人怎么说没有直接关系： https://v2ex.com/t/636465#r_8459703

再有就是目前几乎所有的新东西都会以很快的速度普及，手机行业尤其如此，因为竞争最激烈。

比如针对电脑的问题，我在隔壁某游戏社区有一个回复：
”如果假设 PC 平台性能提升的速度快、频率高，同时假设某玩家一直都是 PC 玩家并且一直都会更新硬件，那长期来看最实惠的选择就是一直以“当前主流性能”为目标升级，这个“当前主流性能”不是卡吧的泰坦 4k120hz 什么的，而是”当前主流游戏能流畅高特效运行”。
如果每次都要上最好的，那该玩家不仅多花了至少一倍的钱，获得的性能提升也会在短短几年内被摩尔定律追平。但是如果你真的不差钱，那天花板也不会比主机低。“
如果放到 V 站上的话，我应该会把“主流性能”修改为”合适的性能“，我个人对此的定义是”两年前主流游戏能流畅高特效运行”——也就是只要不玩最近两年的游戏，配置问题就能解决一大半，老游戏还省钱。

你可以一直保持这样的节奏，一年一换或者两年一换，三年一换之类的，但是每次换都有意比当前落后两年，相比最新而言，每次都少花三成到一半的钱。这样的结果是你不能享受到当前的最新，但是能享受到两年前的全部。两年之后再来享受现在的东西，长远下来就是个”流水线“。
当然这样做有个缺点，就是你死前两年出的东西你享受不到（流水线会断掉） ... 当然可能本站大多数人现在不会太操心这个问题，最大的问题还是”现在的东西你享受不到“。整体来说是个很简单的”早买早享受，晚买享折扣“的逻辑。

针对楼主的情况，楼主可以考虑”租“而不是买。楼主说一部手机用几个月就半价卖出，并且自己也不想保留手机（不是迫于省钱卖出），那么租会是更合适的方案。
当然我个人认为，大多数的营销、首发、预售之类的大部分都是陷阱。相比而言”租“现在陷阱的成分也越来越多，但是它还是确确实实提供了价值、解决了问题的。最后如何选择，需要楼主自己算一下，只买老款，租新款，还是保持现状，再把出二手之类的因素考虑进去，长期下来（也就是按照”流水线思想“）哪个比较省钱。

不过上面两段的这些 trick 都不解决”一部手机用几年“的问题，只是可能可以帮你省钱。如果楼主不知道出于何种原因想要控制自己不频繁换手机的话，那最有效的方式还是从第一性原理出发，尝试改变自己对手机这个东西的看法。

比如”体验“这个东西，每个产品都是不同的，但并不是每个产品都要去”体验“——我拿食物来类比，这个地球上没有两粒米是相同的，但是你要把每一粒米都吃掉么？
很明显不会，米分品种，你最多只会分品种一样吃点。
那么我有一个一粒卖 114514 元的品种，你一定要吃么？
除非免费送大概不会吃。实际上我不觉得这个世界会有多少人把”尝遍每个品种的米“作为人生追求之一，哪怕不同品种的米确实能提供”独特的体验“。
但是我相信确实有极少数人想要”尝遍每个品种的米“，不过绝对不会有人要”尝遍每一粒米“。但是就算给这种人两份米，怎么确定它是”同一品种“（尝一份就够了），还是”不同品种“（都值得尝一下）呢？噢对了还有怎么确定这两份米的品种之前有没有尝过呢？很明显”品种“这个”体验“是人为建构的，”两个品种的两粒米的区别“和”同一品种的两粒米的区别“可能有程度上的不同——但是这个程度多大能算是”两个品种“呢？所以你看”尝遍每个品种的米”和”尝遍每一粒米“一样，其实是个很荒唐的目标。有些人在同一个品种的米中都能吃出差别，有些人吃不出相近品种的差别，但是差得远的能吃出来，有些人可能不常吃米，吃什么品种都觉得差不多。
而吃得出吃不出差别，和你如何对待这种差别，又是两回事，有些人不管能不能吃得出差别，就觉得便宜安全能吃就行，没必要折腾，没必要吃最好的；有些人觉得某一种（或者某几种）最好吃，能吃到这些就不吃别的；有些人就非常上心了，觉得米这个东西真神奇，我这辈子一定要把所有品种的米吃个遍。

你看这都是很正常的行为，米这个例子有点极端，但说明了每个人都可能有自己特别的癖好。所以频繁换手机本身并没有什么问题——楼主如果认为自己的价值可以在手机上得到体现的话，那频繁换手机很正常，这只是你自己的爱好和追求而已。

我觉得值得思考一下的是自己追求体验，或者追求生活的标准，因为就像米的品种是人为建构的一样，手机的型号完全是厂家定义的，所谓的”体验“也是厂家建构的，楼主可以把手机当成米，每周都有新的品种推出，每次宣传的都很好看。楼主家里还有好几袋米，新的米要不要买来尝两个月？不同品牌出了同一个品种的米，买哪个？还是都买？还是直接无视掉？

这话的意思就是：我需要什么样的手机？为什么我可以无视掉新出的米，却非常想买新出的手机？要不要把手机作为自己的爱好？或者说，自己的爱好“应该”是什么？
这个就需要楼主自己来思考了。毕竟楼主如果不玩手机了，多余的精力也得找个地方放，也许是吃遍所有的米吧。

这种书应该是有，但是我感觉不会讲这么具体的问题 ...

@liuxu 优化问题和语言问题不要混在一起
就好比一个厨子把自己做的菜”优化“得很好，但是客人不吃肉 /辣椒 /香菜，优化半天白瞎

拿 11 楼的例子粗略看了一下

36 ms 的汇编：
0x00007f6130116540: mov r9d,r13d ;*goto
; - Benchmark::doTest@30 (line 8)

0x00007f6130116543: or ebx,0x7b ;*ior ; - Benchmark::doTest@25 (line 10)

0x00007f6130116546: mov r13d,r9d
0x00007f6130116549: add r13d,0x10 ;*iinc
; - Benchmark::doTest@27 (line 8)

0x00007f613011654d: cmp r13d,0x773593f1
0x00007f6130116554: jl 0x00007f6130116540 ;*if_icmpge
; - Benchmark::doTest@17 (line 8)

531 ms 的汇编：
0x00007f5b8d070650: mov r9d,r13d ;*goto
; - Benchmark::doTest@27 (line 8)

0x00007f5b8d070653: or r14d,ebx
0x00007f5b8d070656: or r14d,ebx
0x00007f5b8d070659: or r14d,ebx
0x00007f5b8d07065c: or r14d,ebx
0x00007f5b8d07065f: or r14d,ebx
0x00007f5b8d070662: or r14d,ebx
0x00007f5b8d070665: or r14d,ebx
0x00007f5b8d070668: or r14d,ebx
0x00007f5b8d07066b: or r14d,ebx
0x00007f5b8d07066e: or r14d,ebx
0x00007f5b8d070671: or r14d,ebx
0x00007f5b8d070674: or r14d,ebx
0x00007f5b8d070677: or r14d,ebx
0x00007f5b8d07067a: or r14d,ebx
0x00007f5b8d07067d: or r14d,ebx
0x00007f5b8d070680: or r14d,ebx ;*ior ; - Benchmark::doTest@22 (line 10)

0x00007f5b8d070683: mov r13d,r9d
0x00007f5b8d070686: add r13d,0x10 ;*iinc
; - Benchmark::doTest@24 (line 8)

0x00007f5b8d07068a: cmp r13d,0x773593f1
0x00007f5b8d070691: jl 0x00007f5b8d070650 ;*if_icmpge

可见两边都做了 16 次的 unroll，两边的时间基本也是差 16 倍左右
但是大概这里编译器并不知道 outer scope 的变量具体是什么值，所以如果不在循环内赋值，就会强行做 16 次 or
感觉这个优化还没开全 ... 这 16 次 or 换成一次是一样的
当然全都优化之后是个常数，就量不出时间了

@hst001 100L

假设你指的是近年的 3A 游戏
你可以认为看起来过大的体积已经是优化的结果。
* 游戏开发者是有限制游戏体积的动机的。比如游戏受显存容量、带宽的限制是很严重的，所以贴图的压缩很多人都在搞。
* 技术的进步本身就可以优化体积。比如我曾经折腾过的某个 2D 游戏，图形使用 256 色位图表示，该游戏中的一个角色需要 8 方向的图像，每方向都是几十帧的动画，一般几百 K 。敢做的话只要放大分辨率，单个素材几百兆都可以有。但是这只有 8 方向，也就是说转向、在斜坡上的时候是非常生硬的，并且无法更改灯光效果和影子方向。使用 3D 技术实现同等效果，只需要一个几百 K 的模型，加上几十 K 的动作，再加一个很小的贴图就可以。免费送全向的图像，随便改灯光，加动画的边际成本极小。
* 但是最后游戏的目标是尽量最大化运行时性能，因此很多地方用了类似“空间换时间”的策略。

关于贴图为什么这么大，游戏如何空间换时间等可以看我的 https://v2ex.com/t/652487#r_8689152 这个回复。

你所说的“各种奇淫巧计来优化”的时代一般是指早期专有主机为绝对主流的时代。那个时代的游戏很多是为单个平台开发，所以优化空间很大。现在是跨平台为主流（硬件性能过剩也只是 GPU 在高端游戏 PC 上，CPU 在 PC 上过剩（对我就是要黑这代的 CPU ）），优化的主要目标也不是体积。现在的游戏开发者确实相对之前比较大胆，但是不会塞一堆 dead asset 进游戏，这并不会降低开发成本。游戏的体积问题和优化问题并不相关。

如果说游戏的体积真的成了一个问题，我认为问题出在游戏发展的方向上，也就是需求就是错的。

理论上当然是可以共享的，Linux 包管理就做得很好
"很好“的意思是现在我平常使用的唯一 Electron 程序——VSCode 被拆开了，然后就如楼上几位所预料的一样，出现了这种结果： https://www.archlinux.org/packages/?sort=&repo=Community&q=electron&maintainer=&flagged=
点进去会发现虽然 Electron 感觉上无处不在，依赖这几个”共享“的 Electron 包的包两只手就能数的过来，最大用户是 VSCode 和 Atom，以及 Keybase 、Signal 、Riot 等几个互联网应用。并且 VSCode 和 Atom 依赖的版本都不一样——也就是说如果我要同时装 VSCode 和 Atom，还是要装俩 Electron 。假设你装 8 个 Electron 应用，可能这 6 个版本的 Electron 还是都会出现在你的硬盘里（虽然 Arch 的软件源里面并没有 8 个 Electron 应用可以给你装 ...）

尽管如此，相比于 8 个应用需要装 8 份运行库，现在装 8 个应用需要装 6 个运行库，还可以以包管理的方式组织起来，我仍然认为这是一种严格的提升。但是显然这并不直接解决楼主的问题，重要的是这种现象给咱们的启发，我的观察如下：

* Linux 生态系统受 Electron ”污染“ 较少。
* “互联网”应用更倾向于使用 Electron——上面列举的几个 Linux 下使用 Electron 的应用，都是互联网应用或有互联网背景。Linux 生态本身互联网应用较少，所以 Linux 下 Electron 比较少。同理使用 Electron 的应用肯定是桌面应用，Linux 桌面应用也少。
* 要想共享运行时，用户环境必须有一个可信任的、被公开承认的中心全局软件库。Windows 和 Mac 并非没有这样的软件库，这种软件库一直在起作用——MSVCRT 、.Net 运行时、DirectX 、ObjC 运行时、Cocoa 等都是通过这些系统中的中心软件库分发的，但是很明显在这些专有操作系统中，中心软件库仅仅对第一方软件实际有效。Linux 虽然看起来做得更好，但是软件库是由发行版管理，当讨论“Generic Linux”的时候，中心软件库（具体的包管理机制）是一个“存在但不可用”的状态。虽然很多软件并不鸟所谓“Generic Linux”，而是只做 Debian 、CentOS 等主流发行版，并非每个发行版的软件库都能保持最新，因此很多软件在 Linux 上分发时依然将 Electron 打包进去了（ Arch 把 Electron 从 VSCode 中拆出来是社区行为）。
* 这里还要提两个特例，第一是 Linux 的包管理方案并非完美，比如 Arch 一个臭名昭著的问题： https://old.reddit.com/r/archlinux/comments/6jce9x/pandoc_minus_the_new_750mb_haskell_nonsense Electron 一个开发 GUI 程序的库，不过 150M，pandoc 一个 native CLI 程序却要装 350M 的额外库。第二是各种编程语言的包管理机制，就算是做得最烂的，单独来看相比于系统级的软件管理还是要优雅太多。
* 开源软件一般都能实现运行时的共享。开源软件的开发模式一般是核心团队维护中心仓库，所有人在不同的环境下工作（包括核心团队的环境也是不一样的），中心仓库只维护软件本身不维护依赖，这种开发模式决定其对环境要求不能太苛刻。开源也决定了就算开发团队不会做这个事，社区也可以帮忙拆出来。以上这几点都说明，如果软件是开源的，那么共享运行时本来就不是什么问题。
* 非开源软件一般倾向于不共享运行时。非开源软件的使用价值是绝对首位，开发者会选择把运行时和软件一起分发来最小化开发成本，以及最小化用户可能的破事。对于免费软件来说可以减少支持压力，对于收费软件还可以最大化收入。非开源软件的开发者环境一般比较固定，源码换了一个编译器版本就 build 不过是常有的事——并且就算内部发现有此类问题，一般解决方案是统一环境而不是完善项目。另外对非开源软件进行修改技术上和法律上都有问题，所以开发者不做运行时共享，其他人基本没法做。至于用户吃多少屎，那就不是开发者的事了。
非开源软件能做到什么程度？我昨晚刚看了这个 talk： https://youtu.be/2YXwg0n9e7E?t=1723 在这个链接的时间戳，这位曾获得奥斯卡 Sci-Tech 奖的 C++ 程序员自豪地说道：为了解决客户的兼容性问题，他们有个人花了半年时间把 boost 库中的所有 boost 命名空间改名成 hboost，当然这就意味着他们还必须分发一份根本没法拆出来的 boost 。
但是由于上述的原因，就算他们不这么改，也不意味着这个 Boost 的冗余可以被消除。我系统里除了包管理器装的版本之外，还有至少 4 份 libpython 和 libQt5Core —— Electron 并不是我系统中冗余最多的运行时，Python 和 Qt 才是 ... 可见并不只是 Electron 的问题。

虽然我认为 Electron 这个工具的原罪不可忽略，但是我觉得依赖管理的问题还是要和用户界面的问题分开来谈——不仅仅是 Electron 、Python 或者 Qt 。如果你用 Mac，那在你的 /Applications 文件夹下，大概率躺着不少于十个 Sparkle.framework

在我看来，对于闭源软件来说，共享运行时一般是特例，或者说只有不得不共享的（比如 .Net, DirectX 等）才会共享。所以我对楼主的想法的看法是：开源软件已经实现，闭源软件没这传统。

关于上面的几楼胡逼内容：aardio 或者 oidraa 什么的不仅不解决根本问题，更连楼主的眼前问题也解决不了。楼主所举的几个软件都有跨平台需求，并且都是在各平台都有带量用户的带项目（不存在“支持那百分之零点几市场的操作系统有毛用”的问题）。

而根本问题则是 5L 所说，不同程序之间代码共享的问题，该问题广泛地存在于各类开源和闭源软件，GUI 程序和非 GUI 程序中，一个新的 Electron 并不能解决这个问题。

@rockcat Qt 不需要 C++，Python 也能写

黑苹果好吃

我记得小时候还没 Electron 的时候，Windows 底下分发软件把 MFC 之类的带上不是啥新鲜事
现在带个 Qt，Swift 运行时甚至 Python Runtime 也没啥

另外居然有人知道 revery 这东西 ...

别的没啥，两点问题：
* 看腿没啥事
* 节目能播就是符合社会主义核心价值观的，看节目就是在接受社会主义核心价值观的熏陶

楼主真要“缜密”的话就把 > k 的情况给 assert/unreachable 掉

... 更严格的条件有利于发现潜在的问题
更宽松的条件有利于养肥潜在的问题

有几点我觉得楼主有必要提一下（如果有的话）：
* 继承（单继承？多继承？能不能继承 int 等类型？）
* 有没有类似 Java/Go Interface 的机制？
* Operator Overloading/Ad-hoc Polymorphism
* 有没有泛型？或者干脆 大 道 至 简？

@Byakko
我觉得 Adobe 改订阅本来就是给这些软件送客户 ...

楼主的需求是可以实现的，比如可以引入某种形式的回调
当然回调写多了就会考虑如何简化抽象
然后就会重新发明 Promise

“专业”的东西的存在是有其道理的，难度最低的路恰恰就是“专业”的路。忽视“专业”的成果自作聪明班门弄斧往往适得其反
当然楼主的需求可能走不到“回调写多了”那一步，那直接回调可能更直接一点