@justfortest 如果还有心情考虑这个的话，可能还是对自己的健康状况多少有点自信。保重身体。
个人经验，真躺过一段时间以后，这些都还不算啥（只要不是穷到没钱治疗的程度）。

鸡汤就算了，换点现实点的逆向思维吧。
比如说还没到霍金的程度，还是能考虑再找工作的……
比如说生在全球 MRI 收费可能最低的地区，真·福报……（换做米帝搞不好光是诊断就凉凉了……）

看来你还没到不福报也能理直气壮面对亲人的程度么。
真是幸福啊。

typo，1903→1809
1903 还没试。

github.com/FrankHB/pl-docs/issues/6
github.com/msys2/MINGW-packages/issues/5067
看来是限制 anchor 么。

1903 的一坨（疑似内核） bug 连重现都呵呵，然而我就是次次中招。
（验证手机号 smg，github issue 我就不放了。）
至于别的嘛……滚挂几回就长记性了。

@winterx 贴吧早就是屎了，能留住用户的大概也就地图和输入法了……然后都基本没法变现。

@ww2000e 石头烧化了还是会发光的……

不清楚龙芯开源到什么程度，不过这算是抠脚皮大汉 RMS 现身说法认证过了的吧，虽然他那个被偷了之后换了个啥来着？
现在好像时兴搞 RISC-V。
不过整板就别想了。
https://en.wikipedia.org/wiki/Open-source_hardware
拉清单吧。

@enoz 没啥，你可以喷就那些码农撸的 C 代码全不行，我替你手动狗头顶着（
咦，好像 Windows 也顺便中枪了？这我就不管啦……
当然嘛，就内核项目来讲 Linux 本来就有明摆着“生态”上特别烂的地方，比如系统调用接口就别指望有啥稳定性。Linux 的套路是，你要搞什么基于内核的玩意儿，要么你 GPL 直接让我接（吞）管（并），要么你自己对着上游版本挨个儿 biu。（开发驱动的：？？？用户：？！？！？！）
Userland 嘛，libc 的锅刚刚另外婊过，不多鞭尸了。
（其实要逼格的话一个 seL4 全得趴下。。。）

PC 游戏以外？各家主机纷纷表示你 Linux 是 smg。

@iwtbauh libc 不要静态链接这点强调得好，我给漏了。（因为没刻意往作大死方向上想。）
不过这个恐怕还是历史惯性的关系，按道理讲 C 都不提供的功能 libc 就不该多管，libc 本身并没有做系统调用中间层的义务，也不干 loader 什么事。Windows 上 libc/msvcrt 和 kernel32 之类的就是分开的（虽然算上 libc(mt)多版本坑一点都不小就是了）。

@qlhai 几年了都搞不清什么叫自动的过气用户（亏他下文还有脸提“资源泄漏”）的说法看看笑过就好。
说实话，这个还不如“新的都不是好的，好的都不是新的”这个他自己之前对 Go 的特性的评价来得干脆（和准确）。
虽然里面说的 Go 的坏话很多也没多大毛病，不过还是有不少东西是欺负大多数读者外行吧……
比如说所谓通常被叫做“进程”或者“线程”的东西，是要支持抢占式多任务的，自带调度（和 goroutine 实际上更接近）。就算是 building block，那也叫 engine （像 timed-lambda ）什么的，“系统级 continuation ”是什么鬼……
还有除去调度，也不提 CPS 会有怎么样的 ABI 或者其它幺蛾子麻烦（跟他吹 checked exception 时如出一辙），undelimited continuation 在资源上无论怎么实现都是要炸的……所谓“函数式语言只要支持 continuation，就会很容易的实现大并发”基本就是痴心妄想。
看看，这般扯的批评都能被人当真，就知道并不能指望这些语言有多少靠谱的用户了。
（顺便，Scheme 的 cond 和多返回值也有照着 Scheme 自己的设计原则来讲一眼看过去就能发现烂的地方，可能他用的仍然不够多，并不清楚明显能改进的地方。）

整了个新版 Surface Arc，倒是戒游戏神器。。
当然，不适合“普普通通”“左中右三个键”的需求……
……权当跟坐等楼下并排不推荐的反面教材吧：只有一个微动手指放左键区域就没法右键就忍了……滚起来省力过头，然后误按 Ctrl 要逼死强迫症了。（姿势倒是意外地容易适应，普通办公不怎么累。）

腰有毛病，工作姿势自动对颈椎友好了，，，

ABI (e.g. libstdc++)
LD_LIBRARY_PATH/rpath
内核版本和兼容性 (e.g. ELF section .note.ABI-tag)
syscall 实现偷工减料的可能性 (e.g. WSL fakeroot)

……你可以对照现代医学对疾病的治愈率来理解。

@Qiaogui 我不觉得通用语言有把声明做成 primitives 的必要。具体设计看领域特定的需求。

@maxco292 这啥，你说 TAPL 么。。。那个嘛，有 type system 也并不会显得一个 toy language 不 toy 了。何况多数所谓的工业语言光是 type system 上也都挺 toy 的就是了。
不过我个人意见是对没搞清楚要设计成什么样的来讲还不如不看。
另外像是通用做法：
https://aiplaybook.a16z.com/reference-material/mccarthy-1960.pdf
没管 type 不也照样挺 FP 的嘛。
想清楚了针对什么目的（比如 totality ）搞 type system，之后再看看 The Little Typer 之类的入门（虽然老实说，欠了很多东西没讲清楚）。

@ech0x 你一开始提的一些问题比大多数关于琐碎设计选项的问题的确更有意义，能镇住用过某些语言的用户，也能糊住现在的 LZ，但远远支撑不了 LZ （想要）吹的说法。

换些问法吧。（翻译太麻烦的进阶问题仅供参考。）

1:（设计语言时，下同）为什么要考虑静态动态？
1.5:为什么要考虑类型？
1.5.1:为什么要考虑类型系统？
1.5.1.1:Structrual or nominal?
1.5.1.2:Why support array?
1.6:为什么要推导类型？
1.7:Why not (algebraic) effect system?
2:为什么要倒腾什么“面向过程”？（不好意思，这个槽点我实在忍不住了……）
2.5:什么叫“函数式”？
3:为什么要考虑单独对内存进行管理？
4:怎么支持元编程？
4.1:When and why macros considered harmful?
4.2:How to deal with hygiene?
4.3:How to avoid trivial equational theory caused by features about reflection support?
5:为什么 dependent types 更高级……

嘛，看下面的回复，可能关于类型上面 LZ 确实没啥新的想法，否则可以直接 gradual typing 糊脸了。
至于数组就还是别鞭尸了吧，C 的 dimension/rank 光是说法自己就挺乱的。

顺便关于尾递归……这玩意正好我前几个月刚好折腾了不少，补充点附加题给有兴趣的童鞋（糊 SICP 真的是远远不够的）：

1.PTC(proper tail call)/PTR(proper tail recursion) 和 TCO(tail call optimization) 的差别在哪？
2.TCO 和 TCE(tail call elimination) 的差别是？
3.PTR 和 evlis tail recursion 的差别是？
4.为什么 safe for space requirement 对环境的结构有限制？
5.在一个 native 实现上要求不依赖全局 GC，且语言要求支持 PTC，对整个语言的设计有什么影响？

@mostkia 怎么说呢……大部分人看到的巨人其实都挺矮的……

@Qiaogui 可以是 spec 的一部分，但体例不完整。
我比较怀疑你会全部返工，所以还是建议你先整理需求。
（如果照常规的 spec 的写法，你这里是有不少比“变量”更基本的内容是要提到外面写的。）
另外，因为各种这里已经有人提过的和没提过的原因，我建议你最好不要随便说“非常了解”。

@qzivli 虽然 LZ 的设计比较感人，不过这水深得很，别太死脑筋……
比如：
https://srfi.schemers.org/srfi-45/srfi-45.html
http://klisp.org/docs/Promises.html#Promises

@mind3x 别那么悲观嘛……要我说的话，现在所有比较流行（这楼里大多数人包括 LZ 可能有听说过的）工业语言刨祖坟串起来后的设计，还真没几个不民科的。
算上委员会的话可能还好点，但其中有些经典的设计在历史上就是以看上去相当民科的方式溜进去的——比如说，从 ALGOL-60 要求支持递归调用开始。
（不信？随便举些比较有名的，分分钟挖黑历史出来。虽然可能有些槽点外行难以理解就是了。）