@awesomes 劝龙哥有点社会责任感吧。
火候明显不够。啥时候能像乔布斯一样套上抠脚皮大汉的评价再教做人了。

缺乏万事俱备只缺一个程序员的实践，还真是幸福啊。

@prenwang 带新人也有规矩。知道新人不保证靠谱，就不要随意拉别人下水。
稀里糊涂带着会不着边际的人讨论业务问题的项目组，没事浪费所有人的工时，其领导八成就更欠喷。

个人智力投资？
这几个玩意儿整体知识的迭代和过气速率基本算是同一个复杂度类里的（虽然具体各部分跟用户态度不尽相同），资源也都不缺，学哪个都没差太多，兴趣导向好了。

在一个没法 reify 活动记录确保显式释放又没 proper tail call 保证的玩意儿里瞎搞？想多了。
呵、呵：
https://github.com/nodejs/CTC/issues/3
有点意义的例子：
https://srfi.schemers.org/srfi-45/srfi-45.html

@no1xsyzy 虽然你说的出发点我在方法论意义上不反对，但就这里的例子，实际意义有限。
考虑到 POSIX 中 vi 的支持作为 [UP](User Portability Utilities) 是 optinoal 的，并不保证和 POSIX 其它部分一样强的可移植性。
而且，标准并不是一个。例如，更多时候供应商跟随他们的大客户，习惯依赖的是更确切的 SUS 或 LSB 而非 POSIX。即便原则上这些规范不应该和 POSIX 不兼容，但涉及 optional 和版本问题的时候，兼容性问题就麻烦多了，你的出发点本身因此也变得不可靠。
这也导致具体的问题很难彻底被完全概括，但肯定存在已知的问题：一个实例参见 ISO/IEC TR 24715:2006 5.4。
就 UI 意义上的功能，实际你能用，大不分情况并不是因为你用的实现符合标准，而是“恰好”符合标准。