放弃治疗这坨.md 了。
然而官方又作死 deprecated 了 make-standalone-toolchain.sh ，又是一堆 py 交易的依赖……
看来自己玩也迟早得转向 CrystaX 。

@palxex 到了这份上就跟某人就不叫讨论而是单方面教育了。

除去科普意义依旧，这几天我成天撸比下有余的“底层”的东西（倒腾 opcode/modrm/sib/disp 之类）正不爽呢，正好换换口味……贴吧里矫正了点汇编=底层厨然而毫无波动，果然还是没有狠狠干几个自以为很懂 C 的顺手。

@serial 你可知道你有资格钦定什么叫编译器？上面的东西光是喂鸡都够打你多少脸了。（不是我给的，自己翻什么叫 compiler 什么叫 source code ，包括 FSF 的观点上面都有提。）

还“两个符号 0 和 1 ，是最简单的实现”——你特么实现过计算机？没做过别在自己不了解的领域瞎 bb 。

还有……学 C ？这是我这几天看过最好笑的笑话。你不是 C 撸傻了吧，哪来的蜜汁自信在我面前提 C ？我给人校对 C11 和 N1570 的时候咋没发现 C 给你钦定什么 0 什么 1 了。（我看就你这态度这辈子是不用指望给 WG14 舔屁股了……）

看样子你自认为很懂 C 嘛。来来来，给我解释下， ISO C 对 basic source character set 跟 basic execution character set 分别钦定的理由？按你说的 0 和 1 就够的东西，为什么需要那么复杂？是不是说明 C 是辣鸡？

可惜下面“所有的其他运算通过移位、补码、溢出进行换算”就露马脚了。首先浮点打脸啪啪啪。然后就算是整数，哪个逗比 ISA 会拿这种东西“换算”？哦，强行说 C 是嘛，也行：

WG14 N1570
6.2.6.2/2
For signed integer types, the bits of the object representation shall be divided into three
groups: value bits, padding bits, and the sign bit. There need not be any padding bits;
signed char shall not have any padding bits. There shall be exactly one sign bit.
Each bit that is a value bit shall have the same value as the same bit in the object
representation of the corresponding unsigned type (if there are M value bits in the signed
type and N in the unsigned type, then M ≤ N). If the sign bit is zero, it shall not affect
the resulting value. If the sign bit is one, the value shall be modified in one of the
following ways:
— the corresponding value with sign bit 0 is negated (sign and magnitude);
— the sign bit has the value −(2M) (two ’ s complement);
— the sign bit has the value −(2M − 1) (ones ’ complement).
Which of these applies is implementation-defined, as is whether the value with sign bit 1
and all value bits zero (for the first two), or with sign bit and all value bits 1 (for ones ’
complement), is a trap representation or a normal value. In the case of sign and
magnitude and ones ’ complement, if this representation is a normal value it is called a
negative zero.

我甭管你的“补码”脑补成什么词性，告诉我你那坨玩意儿怎么兹瓷 padding bit 跟 trap representation 跟 negative zero 啊，蛤？

跟你说话真 TM 累，你不会连大一学生 C 语言的普及入门课程十有八九是冒牌得被我婊了几年了都不知道吧？

哦，抽了缩水了。更正：
我上面说的位图是光栅图的实现，是和矢量图对立的东西。

得，撸点 parser 就叼毛自以为造完“编译器”、拿规范偷换概念不给 reference 、目无 ISA 和 ABI 直接 bb 错误组成原理概念的，一概以民科论处。再跳的通通按不尊重现役苦力的阶敌清算。
非技术话题不再这里废话。

@serial 没专业知识、眼界和历史常识撑腰，读空气无能也得有个限度。
本来这种口水问题见了无非是能渡几个是几个，剩下的我就是当×乎娱乐同等笑话，但既然诚心想当被科普的靶子就没法坐视不理了。

https://en.wikipedia.org/wiki/Esoteric_programming_language#Piet
需要更多干货打脸请自便。

二进制？哦， ENIAC 用的二进制？或者你能钦定 ENIAC 不是计算机？
常识：“计算机”这货 TM 本来就不管你毛线几进制，几进制无非是为了（不限于计算机）实现方便事后诸葛亮出来的， understand ？
还有你想说现在的哪个计算机用的什么 01 ？有点规范意识的话，你该不会还停留在目无 trap representation ，分不清 bit/byte/octet 的层次上吧？
再告诉你个常识，我上面说的位图是指的和光栅图对立的东西，是“位图”这个词的原意。
规范？ Device-dependent bitmaps 在 API 以上你想要什么规范？或者你以为别人口中的位图就是 M$的 DIB 还是什么来着？
想用序列化格式偷换概念，还是太嫩了。

@zhanfenghai 《宇宙巨校闪级生》笑而不语……

都 bash 了，放着内置 hash 命令不用还 test ，是有多无聊……

@zhengkai 真不能指望理解得了 777 的用户就能知道 ACL 是个什么鬼……成本忽地就上去了。

@gdtv 难道拿 5k 你还多花力气特意去 umask 么（手动滑稽

@wizardforcel “显然通用语言有各种语句，不符合前提”显然是错的。语句是 Fortran 发明的玩意儿。典型的 Lisp 就不管你什么语句。实际上语句完全可以通过表达式求值规则等效出来，没有语句的设计明显还更通用一点。
另外你搞混了太多东西。干掉或者不干掉优先级纯粹是语法上的选择，而是不是能钦定规约得看语义规则怎么设计，后者至少不要指望用 BNF 能搞定。如果你知道怎么给出形式语义以使之和语法的形式一致，你就不该纠结 literal 或者“语句”才对。
@serial “解析的目标是什么，是一大堆文本”这个显然也是错的。之前提过了，一般意义上的 Lisp 就不要求输入是文本，这不表示 Lisp 不能编译。还有纯位图的语言呢。连 tokenize 都不必要的情形谈何 parse 。
当然，你可以像 FSF 一样争辩定义“源代码”的“人类可读”的具体形式是指的什么，不过人家是有政治目的的。我不了解技术上存在什么必要理由去缩小“编译器”的外延。

@serial 你对编译器理解也是有问题的。编译器输入的源语言不见得就得是文本流的形式，比如可以是已经 parse 过的 AST ，这种情况就不需要处理 delimiter （要处理也是代码里自己实现的逻辑）。
大部分主流语言的确要求源代码是文本，但既然考虑 Lisp 就没法直接这样断言了。

@wizardforcel 是，光提性能，垫背的多了。然而你提的这里除了 js 哪个都没有那么作，显然相对比较老实，应用领域比较固定。
js 自己有另外的大波槽点所以在这里不需要怎么强调。
另外你对语言实现的理解确实有些拙计。
分析运算符不需要是验证 grammatical rules 的 parser 的工作——的确“复杂性都在后面”但是对付起来比改 parser 方便太多了（即便绝对工作量不一定小）；
复杂度需要考虑，但即便是设计实现 DSL ，通常也不会是需要最优先考虑的事项；
写死运算符要通用容易增加维护成本，不仅体现在语法上，而且影响语义规则的复杂性；
对于通用目的语言，即便只考虑语法，按你大大咧咧的策略，一不小心很容易没法“这个位置就应该是个 token ，不是就不合法”（典型反面教材： C 、 C++、 Haskell ……）。

@serial 其实实际项目确实很多时候不需要写 BNF ……简单的文法都自己手撸 parser 了。
虽然我在项目里钦定语言 spec 的时候还是加了点 formal grammar ，但也得结合项目需求而不是直接套用 BNF 。
而 Lisp （严格来说，仅指使用 S-expression 为基础 syntax 的 dialects ）在这里更简单之一正是因为不需要 BNF ，随便什么 CFG 都能应付，简化成纯 S-expr 直接都不需要归纳 grammar 无脑 LL 就行了。

@SNOOPY963 不愿意让明摆着一整天用不到的东西后台。 WeChat 冷启动确实也快不了哪里去，但至少我的 Android 5 上还是能感觉得出两者之间还是能感觉出明显差距的。
其实我倒是能接受让支付宝跟某些银行客户端一样默认常驻，然后提供明确的 UI 彻底退出。间隔不长的两次支付之间需要重新打开是很不爽的（嗯比如刚才我遇到的），特别是手忙脚乱需要开另外的 app 刷另外的东西然后再换回来结账而后面有人排队催的时候。

另外，对于题图里最后一个问题，因为我不怎么用所以无所谓专注。
倒是 QQ 有时候也会在作死边缘，有一段时间登录都卡得动不了。于是那段时间果断放置 play 了。反正常用重要联系人手机就够用；移动端除了打电话发短信以外什么都慢，能 PC 干的就懒得倒腾手机了；强行无聊的话审 IRC log 也来不及。
大概不管怎么考虑用户黏度，对于多数能产生盈利的用户来讲 SNS 作为增值服务要紧程度始终排在支付和 IM 后面这点是不会变的。

越做越烂大概不假。
今天升级支付宝一打开没点几下就无响应，反复了好几次之后总算正常了——卡得和以前一样。
但是手续费差距这条放着就死不掉。
我附近微信都是中老年大妈用得比较 6 。主要习惯可能还是看网龄，以及常用联系人的影响。 2010 年前开始玩的，多数没有那么高的依存度。周围没有 00 后，所以这部分我不清楚。
聊天记录同步这样的功能不算影响体验里排第一位的，所以要看跟啥比……如果是 uwp 那种复制粘贴都不灵光的 QQ ，秒都不需要秒。

比较能直接比较的 WSL 的差距，猜测是 M$自知 NTFS 太笨重所以在 WSL 实现文件系统驱动塞了些特技，调缓存之类。
嗯， Naive Windows ……