@skywind3000 也不是说好为人师，就是看不惯人太菜，还污染环境。
（我才算是发现有人 at 我的用意了。）

0) 你爱怎么写是你的问题，但倒垃圾就是公德问题了。这是常识。

1) 当然菜鸡多的是，人家 STL 说，why is .h ever deprecated ？我还笑话他不懂 deprecated 是 discourage 呢。但是人家也没脸说“我爱怎么写怎么写”啊。

2) 画蛇添足一看就是丈育。废话多，浪费流量和硬盘，看着碍眼，难理解？

3) reinterpret_cast<char16_t*>还是 reinterpret_cast<char32_t*>都不决断的就别口嗨 ABI 了。当然 C 厨嘛，盲猜从不担心 TBAA ，本来还正好省事。
还好意思氵你乎回答大言不惭，谁让你脑补 xxx_ptr 就是 shared_ptr 的？倒是有另外一个跟引用计数没屁股关系的常见的 xxx_ptr 的常见实现还真就有臭名昭著的 ABI 问题，咋不提了？
v8 核心代码里是不是到处指针飞，不碍着它要是不那么辣鸡就更有性价比啊……但是 Google 的那啥 guideline 承认了，他们就缺脑子比较好使能把 C 艹 用对的人，那这现象又有啥不好理解的……

4) 真不想跟小朋友废话……github.com/FrankHB/pl-docs/blob/master/zh-CN/typing-vs-typechecking.md#%E7%B1%BB%E5%9E%8B%E6%AD%A3%E7%A1%AEtype-correctness
（虽然这个倒是真的建议所有人理解。）

5) 懒得看。

@ColorfulBoar 本来就不需要 LSP 啊，什么 LSP ，我就是人肉 LSP （战术后仰
除此以外别的 LSP 顶用？

不过带 template 套不套 inline （就算类定义里）倒是真的不大一样。（大概也就这原因 libstdc++里的类定义里的 template 经常有不省略 inline 的。）
至于代码生成，always_inline+flatten+noinline 明显更顶用点，但是的确有少数就得加上 inline 才会比较不那么欠揍的情况。（比起 github.com/FrankHB/YSLib/blob/master/YFramework/source/NPL/NPLA1Forms.cpp#L2598 或者#L3410 这类抽风当然还是小儿科了。）

@pisc 这种水平放吱扔过去一坨 nano 怕是都绰绰有余了。

要专业角度评价的话，我只能说：

(1) 我不需要理解非得把大部分日常或者工作时间怼编辑器上的其它专业人群的需求，反正现在和以后我不用这样。
当年我不得不怼编辑器的情况，比如 X51v 铁笔戳上万行代码，要避免浪费生命的限制可是苛刻得多了，这些年来也不大有兴趣再次体验这些问题。（尽管批判 JB 我还是喜闻乐见的。）
(2) Emacs 还有个老不死的 elisp 至少能拿来作为长时间不会过气的反面教材（比如 dynamic scoping 遗老）来批判； VimScript 这种最近还想在大版本号掀什么煋闻的东西，除了煋闻外还真不大想关心。
真要批判“精心设计”过的 DSL ，racket-lang.org 上面一抓一把拎过来不香？

@cheng6563 很多设计是因为脑子有坑是对的，但说句公道话，Java 泛型哪来的脑子有坑的设计，在就是根本没设计，搞得后来不适合用不坑的方式扩展了。（ C++模板也是在完全没管参数多态的 C 上加的。）
核心标志就是 JVM 不支持泛型的类型元数据。这导致要么实现成 C++那种翻译时展开，要么类型擦除，都可以实现不依赖运行时元数据。
@camliar 兼容性方面说得有问题。
如果选用编译时展开，仍然可以二进制兼容，类似 C++多了 name mangling 以后原则上也能支持 C ABI ，无非是要多出来 linkage convention 。相比 C++考虑互操作问题要求用户手动 extern "C"区分，这个在 Java 里可以隐式自动解决，毕竟 JVM 在 spec 层次上完全控制 loader 的细节，多加 phase 重新生成代码也不在话下。
只是这样毫无疑问地会更复杂，而在 Java 的维护者的潜意识中不太值罢了。
@nothingistrue 工程上来讲.NET 那套更符合实际需求。
这不是靠山大不大的问题，而是如果没觉悟搞定多版本共存，二进制分发代码迟早变成 DLL hell 还可能到处依赖错误的屎山，要么就是用户自己实现备胎。这历史上已经重演了很多遍了。CLR 其实也不厚道，GAC 自己还是分版本的 hell ，如果把这方面控制权给用户（系统管理员）可能还不会那么烂。
@dcsuibian TypedScript 作为动态语言情况有点不大一样。
原则上 ES 实现的 IR 不需要公开，TS 实现除了编译器，也可以多加辅助运行时实现类似 CLR 的元数据，甚至干脆 TS 自己一个库就实现了。所以就算一时比较坑，也不碍着以后再慢慢加上改进特性，而可以做到避免有明显的兼容性问题。（ ES/TS 自己具体特性设计拉胯不够容易实现出来这样的运行时，非得依赖 ES 的运行时开洞，那就另说了。）
Java 不一样，JVM bytecode 就是 bytecode ，和 Java 源码是两回事。Java 作为静态语言就没这种扩展取代 bytecode 地位的余地，想要改掉就要差不多 Java 到 JVM 整个设计竖着砍一刀挖掉重新填埋。
@someonedeng Go 是想学 CLR 这样在 C++和 Java 中间划清界限避免缺陷，结果画虎类犬：
www.infoq.cn/article/xprmcl5qbf6yvdroajyn

@djoiwhud ……我其实就只提了反例没给出明确结论，不知道你所谓我的结论是哪来的。

除了原始主题的和你更打不着杆子的结论外，我补充几个要点吧。

1. 就算抛开编程不谈，很多教育问题跟年龄没多少关系，至少没那么大的直接关系。
我说过了，差别是“系统训练”。积累不足，所以解答不了一些问题，这很自然。
积累是需要时间的。
如果启蒙得早，一样可以解答出来。我说的反例也全是这样。
你这里的实验设计即便能使结论的普遍性没疑问，也只能证明普通的小学生低年级数学教育的累积年限通常不足以回答这些问题。
要支持你的结论，那么至少还要有提前教育的对照组。

2. 从某种意义上来说，这些小孩确实是挺笨的，都达不到有必要学习编程的门槛——教了基本白教。
这倒不是说这些小孩天份一定差，而只是说天赋还不够到克服学习年限和保守的教学广度等方面的劣势而已。
一定程度上，更笨的是没能力分析清楚这些问题的家长，以及抱有刻板印象自作聪明的你。

3. 我要从另一个侧面强调学习编程跟年龄普遍无关（只要有足够年限的前置基础知识学习的支持）：大多数成人其实在编程上也没学得好到哪去。
虽然你给的这个例子上超过 12 岁的小朋友就不会翻车，但这只是一小部分前置知识。正确理解一般意义上的所谓“编程”是更难的问题，难到你区分年龄也没多少用。

比如我给其他人的回复中提到，不理解递归的人，很难真正地理解了 for ，就算会用 for 去写代码。因为理解具体语法和语用相对系统性理解知识体系来讲真是小意思，一不小心小朋友死记硬背都能蒙混过关了。但是就算会做对要求 for 去写代码的题就一定算是“理解”了么？显然还有个仅仅因为这题目只是要求你用 for 于是蒙混过关的可能。
所以我会把真正理解的门槛提升到“无中生有”，用掌握使用更一般通用的知识来提供等价效果来衡量理解程度。但这样更不容易出标准化试题，非得出题画风就类似：
给定一个没有 for 之类的语法的语言，如何用其它特性实现 for 的功能，或者给出理由说明这种语言不可能实现这种功能？
——这就有个鸡蛋问题。如果学员没有接触过已有语言的 for ，怎么知道“for 的功能”是个什么玩意儿？
于是，如果要刨除这种任意的具体“实现细节”的知识，那么递归这样的关于“如何描述计算”的框架性知识就是不可能逃避的。非得逃避，都没法鉴别出学员到底是不是只是会了个 for 的套路，连循环（迭代）都没理解了——注意，迭代只是尾递归的变体。
这里考察的就是编程的真正基本核心技能之一。（重复：会不会用 for 之类的具体语法去写东西，真不是什么大不了的事。）就这么个基本知识，偏偏还有不少半桶水咣当响的拎不清重点，还能有不少强行跟实现性能扯上关系所以“不建议用”，也是呵呵哒。

总之很遗憾，大部分成年人编程的水平可能水得出人意料了。
基础不牢靠不说，更上层的东西也要划水死记硬背，不懂相关历史和知识点在整个体系中存在的意义，为了给自己理解的坑擦屁股搞什么“模式”（ t/599048 ，t/835769 ，...），拉着别人一起坑……

造成这种水货问题的原因之一是对编程学习内容上的一些刻板印象。这类问题对业界的毒害比所谓少儿编程对业界的影响明显大的多了，以至于要不是你的刻板印象也与之有些相似的可比性，我都有些懒得怼你这样观点。

题外话，虽然无意散布焦虑，基于公益目的地图炮还是得放：趁早转型深耕其它业务（包括管理），编程这个业务真不适合没天赋的大龄程序员，不管合格的后浪多不多，迟早会被淹没……何必损人不利己继续卷呢。

@wangxiaoaer 考虑 hyperv_fb 糟烂残废到让人忍无可忍（乃至 vczh 都没好意思自卖自夸而强调 Hyper-V 不适合桌面 Linux ）的程度，要是 hyperv_drm 的开发者被刺激得一步到位而成功实现（相对）非常神奇的改进到能用也不奇怪……但是现在 VMware 我这边已经流畅日用无压力了，而且 Hyper-V 网络配置麻烦的传统艺能应该没什么变化，就算都整清楚了没新坑，基本也就一个不用另外装第三方软件的好处（但是我都已经装了 VMware……），于是实在懒得试了。也许下次重装 Windows host 有机会再试试。

@lwc645089781 本来我也有一瞬间这么推理过，但是这里不对，因为赋值是传统上小学生更不会接触的概念。不管是相等还是等价还是基于等式的推理，都是传统数学的内容，而赋值完全就不是，纯粹的数学课里本科都不一定会有（这类 deduction system 的内容）。
（等式的性质一年级可能都会碰到，虽然那个也许只涉及自反性而不涉及这里需要的传递性，但是教得急一点类似方程的东西三年级就可能会摸得到；就是不知道现在减负是不是真减到把非得方程拖到四年级以后教了。）
所以除非最近的小学数学教科书加了很多我不知道的料并列入考纲，不太可能有这种问题。

@snailya 以我自身和接触到的普遍经验，确有个别领域儿童的后天习得能力是比成人占据绝对优势的：口语语感、绝对音感。
当然，大多数情况都因为缺乏经验等原因更不占便宜。

@djoiwhud “杠没意思”是废话。你会引起我回复，也是因为你说的“专业回答，不用客气”。

专业和专业之间水分不尽相同。专业不代表可采信程度高，甚至有的专业可能外行都能轻易批评而没什么逻辑破绽——因为专业相对于要解决的问题来说普遍太水了。
R. 费曼就直斥“社会科学”是伪科学，而整个心理学就是代表。这显然不是专业意见（科学划界问题属于科学哲学，而费曼在此并无建树），但不见得反面意见就是对的——心理学家几乎全对科学边界问题一无所知（即便偶尔知道，大头可能也得归功于某些硕士学位非专业必修课的课程计划上），而心理学能算不算科学甚至都不是个别人的疑问（有的分支像精神分析这种不算科学，差不多专业心理学家都快都同意了），费曼充其量只是强调“伪”的冲突罢了。
这样的学科整体不可靠程度和该领域的历史声誉多少有点关系，也间接决定了从业者的底气。尽管自然科学家没能力跨界争夺诸如科学划界问题的大饭碗，但是形而下地批判当代哲学还是没什么压力的——S. 温伯格写过《反对哲学》，S. 霍金写过《哲学已死》，凡此等等，这都是建立在当代哲学相关现象的反馈的迟钝和无能的现状上，以至于物理学家披马上阵取代了哲学家的工作地位（即便好汉不提当年勇，先不管自然哲学的历史好了）。
当然，“科学”算是个通常仅仅是个对外行比较靠谱的帽子（以至于装作伪科学会有收益），不过这里的现象是指是区分不同“专业”的可信程度的相对性，并不限于科学。L. 鲍林就长期鄙视医学界对维生素 C 建议摄入上限，即便医学算是公认的科学。医学在这类机制上的无能是个很大的原因。

类似地，虽然把编程方面的理论粉饰为理论计算机“科学”是十分可疑的（就科学哲学的观点来讲，它更接近模型正确性不受实证限制的数学而非科学），不过在关心所谓编程的效果上，还真没弱鸡到轮得着心理学来碰瓷。至少，在没更实质的内容被厘清时，自指“专业”而 [窃据作为解释现象的依据的主要地位] ，是欠缺说服力的， [可以视为误导] 。
先前我顺便拉上了教育学来检讨数学教育历史的失败，也就是多给心理学在此类问题一个台阶下。
而从心理学以外的另一角度，我多需要批判的是，恰好心理学的普遍方法论迎合了近年来这类专业中一个很不好的风气——依赖炼丹（虽然炼丹正经来说其实让计算机科学更像“实验”科学）。到这里就没鄙视心理学的意思了。
新数学运动失败的锅主要是教育学（包括素质过关的教师储备的问题），跟心理学其实没多少关系，结果普遍却是数学家背锅了。这是一个很不好的历史现象。你对这样的主要时间 get 不到 point ，显示出对当代教育史毫无所知，就更没提这里问题的说服力了。不论强调家长还是“学者”的身份，都显得在专业性上掉价——不管你如何理解儿童的心智，都不表示你理解数学教育本身的问题——何况我是没看出你多理解儿童的心智。

我需要另外指出，对问题解答多一个角度通常不是坏事，但是遵循问题领域的内容先来后到应该是自觉，否则只会体现出你对问题内容的整体性的无知；这是跨领域的基本共识。
这方面拿出“体系”说事是没多少意思的。即便科学哲学中有这类流派（以 T. 库恩的学说为代表）也多少被相关人等接受，除了在和碰瓷的民科的敌我矛盾以外的情形，这不大会被作为决定性因素考虑（经常版面费之类才是更实在的问题）。因为体系内外早就有大致关于问题领域归属的共识，通过三言两语标识是否自己人并不比呼吸困难多少了。当然，你若非得觉得（因为被划归非科学而引起）你认为的那些学者的“体系”与现有的明显更大的体系相对立，那就是自讨没趣的鸡蛋碰骨头的小品了（例子参见索卡尔事件）。
大多数学者，不论自己感兴趣的学说是否被接受，都会继续干自己的活而不会掺杂这种注定失败对立的情绪。而没眼力见会对争夺相关话题的管辖大打出手的，最终就是欠教育的“不专业”了。

@djoiwhud 虽然少儿编程几乎全是扯蛋，你说的也挺扯蛋的。

首先理解编程跟理解 Scratch 是两回事。Scratch 就没几个实操上的能作为典型的可编程要素，撑死只能教一些编程能做什么，而不是编程是什么；理解这个对理解编程也没帮助（编程能做什么根本不用通过理解编程就能想明白）。

其次什么叫“真理解”？你如何设计测试来检验的？
你甚至都没给出你期望的基准答案。如果预期是 a=b, b=c => a ? c 这种填空，正确答案是 = ，那 9 岁小孩不太可能做不到。这东西就是个智商题，要理解含义也就是一年级下二年级上的水平，即便正经通常是三年级教的。
如果你想要小学生讲清楚什么叫“关系”那就是强人所难了。这至少要求他们要把二元关系从无到有发明一遍，而没经过系统训练做不到。这跟心理学倒没什么“关系”，做得到大半是数学史上留名的人物。
反正我 7 岁时就知道=，在没提示的情况下分析明白等价关系大概用了 7 年。但是明白为什么等价类是“类”（而不保证是集合），又至少浪费了 3 年。人冯诺依曼 8 岁还口胡微积分呢，人比人气死人，你劳什子心理学只管事后诸葛亮观察放养炼丹的结果而不是预测积极干预的上限，是真没排面的。
历史也证明了，教育学和心理学都救不了新数学运动的失败。

@ThomsKim 不选择“市面上比较流行的图形化编程”做得对，因为基本就是智商税。“培养兴趣”而不是教育解决问题的实际方法，从来就是人口红利下筛人的借口，连兴趣要投入资源就已经输了。
不过，我不觉得有谁能在理解清楚递归（不止是函数的递归调用）前真正理解清楚 for 这种 tail recursion 复杂语法糖；而理解 if 也够呛，因为大多数语言中 if 就是个 non-strict evaluation 的 special form ，只能当特例强行死记硬背（毕竟基础不好教 Church boolean 太不现实）。——不管天赋如何。
相比之下，不会用 if 和 for 写代码不是什么大不了的事。

我用 WSL1+VMware 。

WSL1 当主力，是因为共享资源方便程度上无可替代，虚拟机始终低人一等。（当然非得拿 Win32 app 作死直接编辑 DrvFs 下的文件搞烂了另说。）磁盘 IO 能比原生 NTFS 更快，相比之下挂 vhd 就很看脸了。
缺陷同样明显：内核残的没法用内核模块，一些系统调用实现不全，只有 x86_64 ；不能换 init ；但是大多数情况没什么问题，或者有变通。
没图形硬件加速，但配合 VcXsrv 日用桌面问题不大。

遇到解决不了的需求（很少）再用更重量级的虚拟机。

虚拟机有虚拟机的通病（不是一台机器）和优点（不是一台机器但你真的需要不同的机器；以及快照）。
Hyper-V 就不是设计出来给桌面系统用的，别指望什么体验。hyperv_fb 卡得没法用，还不支持高分屏。hyperv_drm 没试过不过我懒得折腾了。
以前用 Hyper-V 还有和其它虚拟机（包括一些安卓模拟器）共存的问题。现在开 Hyper-V+虚拟机平台用比较新的虚拟机问题不大，但仍然可能是个问题。安卓模拟器能用的就 BlueStacks Hyper-V 版。

VirtualBox 就是摆烂。之前试了下，默认还是卡翔（虽然没 Hyper-V 那么夸张），配置 Hyper-V 共存出错发现论坛里的根本都不清楚自家产品的最新功能。不折腾了。

开箱即用的基本也就 VMware 了。

至于 WSL2……都自己搭建环境了，非要用还不如全功能的正经虚拟机。而且至今还有 250G 硬盘限制。

@Osk 你是不是把 WSL1 和 WSL2 的 IO 性能感人程度搞反了?

@felixcode 如果只是公开密码，没说清楚密码是谁的哪个账号的，识别不到个人，那就不叫个人数据，不违法。否则随便公开一个弱口令都能抓几次？
要是事主自己跳出来公开承认就怪不得别人了。

@totoro625 Windows 在这件事上什么时候有责任了？ Windows 有自卖自夸说它能保证分得清木马不放过一个？ Windows 跟用户约定过系统中木马要承担什么责任了？还是说这木马算 Windows 的一部分？
用户再可怜，也没本事躲在系统后面为自己的主动操作引起的后果免责，谢谢。
不服的欢迎去告微软。

项目屎和代码屎是两回事。到底是往代码堆上挤乃至自己亲自往上拉屎淹死同事还是找远离代码的地方瑟瑟发抖，看你喜好和本事了。
如果真只剩下一回事，倒也不用在意了——反正结局都差不多。

冷知识，这年头进程杀不掉算不了什么诡异的了，比如现在 taskkill /f /im msedge.exe 也可以杀不掉还会把系统卡粗翔。（姑且不确信你这 Chrome 版本有没有那么跳。）

@icyalala CI 确实是没问题因为环境可预测，不过瞎 pr 有紧迫到用得着这样对付么……
（虽说一般通过的用户也没法指望想太多……github.com/kifuan/helang/issues/271 。）

@paradoxs “真有意思”，然而几个回复下来，也没看你说清楚“意思”在哪。是在说“我是阿 Q”么？

用户要是真当做供了祖宗被电脑玩了，说不定还能挽回点实际损失，也不算被白嫖；反过来，要是拿你的话当真，结果什么都不会变，单纯看你一个劲儿地无能狂怒浪费时间罢了。或者加入你一同无能狂怒来互舔伤口？
为了消除我浪费时间的不快，我不得不承认看你表演，倒的确是有意思的。

@icyalala 极不建议默认 -Werror ，即便是自己控制的项目。要是刚好有用户升级了新版编译器多检查出了没在你这里报的 warning 然后变成 error 就糟心了。要是源码发行版用这种默认策略很可能整个系统动不动升级失败。

@mikeven 不好意思，我的错。我原意是想说轻松压缩 10 倍（或者说跟 7z 的不压缩的“存储”配置比）并在再花费近似时间下）显著比 LZMA 效果好，但不是说比 LZMA 高效 10 倍，结果串起来了……
实测的一些比较适合这样压缩的文件： https://osdn.net/projects/yslib/releases/p17163 ；压缩 10 倍算保守，实际近 20 倍，而跟比较快速的 LZMA 比结果大小一般好 2~3 倍（ PPMd 字典往大了开 1536MB ，效果更好，压缩时间影响有限； LZMA 字典对结果影响不明显）。极限情况 LZMA 也 Ultra 压缩结果的大小其实并没差，但是压缩和解压时间就……太不实用了。另外这个是几年前测的，近年也许实现有改进时间差距可能缩小，不过我没见算法有明显变化，也没重试。

@FrankHB 更正：搜了一下最近的 iOS 通话录音的解决方案，后来发现原生还是没支持这个功能，现在用户还是得靠第三方方案变通。
所以这里其实没变化，仍然体现出用户在一些时候客观上无法省心，苹果对此不上心且傲慢的状况。