这玩意儿抽风起来还挺麻烦的。
我之前 22000.1xxx 装了好好的，然后因为排查一个蓝屏卸载了更新回 22000.1 就跪了……出不来桌面，卸载也失败。之后 Discussion 中找到手动删 dxgi.dll 大法，桌面是能启动了，但还是卸不掉。。。手动改注册表干掉了之后重新安装，总算是能用了，但是任务栏右键菜单死活搞不出来（属性可以 rundll32.exe "C:\WINDOWS\dxgi.dll",ZZGUI ），就这么晾着不管了。
（最失败的是那个蓝屏根本就没解决：github.com/microsoft/WSL/issues/7778 ）
我现在想搞清楚这是现在不再支持 22000.1 还是卸载残留的关系。
PS. 现在用的是看上去和原版 bug 兼容的汉化版：github.com/ZetaSp/ExplorerPatcher
PS2. GitHub 刚给我推了这个，暂时没试：github.com/HerMajestyDrMona/Windows11DragAndDropToTaskbarFix

你要优雅，就先干掉 computer::computer(cpu*, gpu*, memory*)这种看不出让你怎么干的废物签名。
基本上除非在写分配器的实现，你一个一般应用的作者，没什么理（资）由（格）在 API 中用指针。
（写内核之类的东西原则上几乎都得依赖 ABI ，使用的假设比 C++的指针多得多。）

@dandycheung
workaround 变通
ad-hoc 特设
不一定是过渡和应急，因为可能一直就在那了，比如大把的 overloading 这样的 ad-hoc polymorphism 也没几个想着要去干掉的。

ad-hoc 原意不是“坏”的，不过除非是临时的，经常就当做是揶揄三脚猫设计的讽刺了。

不好意思，上面 at 错了。上面应该 @microxiaoxiao 。不过下面一段通用。

@changnet 你之前的公然扯蛋，已经有些涉嫌侮辱业界和消费者智商了。路人还没资格反对你的观点了不是？
你再看看到底这里几个人不同意你的观点？你能以看不懂我说的搪塞，还能一个个全塞抹布过去？

给类似捧臭脚的：
做业务就做业务，不会写代码的就不要给写代码的捣乱。非得强行全栈的别指望好下场。
业界常识：这些工作之间互相不可替代。你可以不会其中一项，但是不会的活就得别人做。要么老实全当碉堡侠，剩下的相当于外包出去了。
再者，没被市场淘汰和正在被淘汰的厂，哪来那么空给在这种层次的问题上浪费时间“查接口”来糊弄。（我是有些奇怪有些厂不给加班费的超量工时是不是就是专预备给这种活了……）
退一步讲，作为专业人员，就是要有合理理由自认为“不会”，那也该直接按不合理需求怼回去。自己先怂了，达不到对方期望的这类岗位的一般常识性的要求，怪谁？

@eason1874 我有说“不是”了么。
当然你要是习惯只看个标题不看内容，而容忍挂羊头卖狗肉，那你自便，不过这也不是给微软标准化工作质量低劣辩护的理由。
顺便 ISO 在这种 ECMA 才是第一现场的东西上没什么可以说的，基本就是抄过去，不负责起草——毕竟 ECMA 的质量是够抄的（ IEEE 同理）。而相比之下，MS 的质量太挫没得抄，这也是传统艺能——否则当年 C++/CLI 提交给 SC22 就不会直接被嫌弃了。

@camillo 大概是“门诊部”之类的。

@changnet 你需要清楚，我没有说需要准备大量不确定的题的答案。这种问题质的评价，就是因为 OP 直接出的最水的一类的几乎没法更水的送分题（比较排序 naive(O^2)不 naive 的平均 O(n log n)），甚至因为结论过于容易被人死记硬背，而被许多人直球认为没资格做面试题。直接按这题的结果拒掉人，不太会怕误伤（至少比卡学历靠谱）。
如果这个层次的问题都要排除掉，那么算法差不多整个就不用问了（于是这人“熟练算法”也白写了，gg ）。

你提出“这么多种”×3 ，说明你对这个入门领域的问题层次以及难度梯度也是几乎毫无感知，所以才会把差距离谱的不同要求混为一谈。
对一般开发者来说，这里的结论完全不需要刻意记。稍微瞄过点算法入门的，都知道排序的平均复杂度形式上实在“正常”得过分，基本就 O(n^2)和 O(n log n)这两个答案二选一。因此甚至都不需要知道快速排序是个啥算法，这名字一听就不 naive ，所以是 O(n log n)。
退一步讲，现场“常识”就能推断出比较排序下限不可能少于 O(n)，掰指头算个 C(n,2)就该知道 naive O(n^2)，然后中间补个最常见的 log 而已。除了 O 本身的定义，就是高中数学（甚至……小学奥数）。这很难吗？
（排序默认都指时间复杂度，空间另说，稍微没那么水。）
你之前有提出要求理解算法的“效率”。对渐进复杂度这么容易复读（不刻意背就自觉记住）的形式都不去强调的话，如何去要人理解更普遍抽象或实际更妖孽的问题（比如卡常）呢？
你所谓的灵活应用字面上就比这里的问题实在难了不知道几个层次。

对职业开发者来说，见识少还是一层问题，还容易学习培训弥补，而少根筋是更劝退的。
比如上面有人说调用别人东西不要在乎这种问题，这是完全忽略了他的用户（可能是最终用户，可能是调用他的工作的开发者）的感受——他觉得锅全是他调用的，所以不管，顺手当做不存在实际直接甩给用户了。用户：exm ？？？

@lzgshsj 因为这问题水到一定程度了。正常来讲能长期摸得下去所谓后端需要的代码（反正不会是能把复杂度包袱卸完的纯声明式语言写的）的人，就算完全没有复杂度的概念，也会对几个重要复杂度类之间的区别直觉上有反应，要有瓶颈就是他们不知道 /发明不出来大 O 记号的严格定义罢了。
但现在这人是至少打算表现出知道 O 那么回事的。所以要么是脑子实在迟钝真不适合碰后端代码，要么就根本是死记硬背半吊子，态度就不适合这类工作。

其实也就是现在语言花样多了才能那么容易蒙混过关。古早没所谓结构化编程的时候，混的下去的基本都是自己会发明栈帧之类的过程调用的实现的，否则写起代码来自己都能给自己烦死（特别是对照别人已经能自己发明出不那么烦的东西了）。
某种意义上，现在“写逻辑”当借口被滥用多了，也慢慢像是这种少根筋低效低能的贬义词了。

@microxiaoxiao 你哪来的“瓶颈一定不在我”的余裕？或者你就是一次性碉堡侠，让你调用一次必定卡？调用几次就卡几次，全然不对业务实现质量负责的是吧？

@changnet ？不知道这种复杂度是怎么好意思占着后端的坑摸代码的？你当你茄子啊？（人策划都不见得敢那么划水、、、）
看来比 OP 这个应聘者还虎啊，现场瞎蒙都省了？

@lululau 问就是“算法”对实际开发本来就并没卵用，偏偏还很多人吹……实际上其中硬要有点卵用，那么最容易的恰恰就是对常见的复杂度的印象，因为好歹能帮助快速选型别墨迹着犯傻。
如果这点捡垃圾的价值都没有，直接写清楚“我不会工程需要的任何算法知识”，别骗人取乐。

@witcat 那么浪费人时间拉仇恨是哪来嫌弃人背后念叨的底气的，武德充沛？

@Trim21 BitBucket 以前是 hg 大本营，若干年后始乱终弃直接舔 git 了。
这还不如 GoogleCode 直接关了得了。
还有那个 wiki 的感人 md……常年不支持 inlined HTML 的奇葩，不知道现在改了没。

@eason1874 是多少的问题吗？

你要提正儿八斤的标准，那行，看看 ECMA-334 的版本断成什么样了？
标准里说微软叫 destructor 不对，应该叫 finalizer ，之后微软的文档照样不听不听和尚念经。
微软自己怕是都没好意思装作热心标准。

不接受重写只有 revert 。
能 push -f ，那就 git replace+git filter-repo （事先保存好 config ）。
简单点就 rebase ，不过不保留时间戳。
不过在此之前先学会 cherry-pick 和 format-patch/apply 吧。

@eason1874 国外巨头……标准？你确定？

github.com/microsoft/TypeScript/issues/15711

这还是主流大厂里我能最省脏话的产品了。

然后回 OP 。

原因很简单。
一个字：菜。
二个字：很菜。
三个字：非常菜。
当然也不是全是人的原因，毕竟术业有专攻，有时候菜是理所应当的。

说个临时想的段子：有的人觉得 context 应该翻译成“语境”，我倒是觉得翻译成“上下文”反而更好，至少信达雅里信是比较重要的。
为什么？因为 context 在形式上就是 some form having a *syntactic* hole in the meta language 。(*Emphasize mine.*)
作为程序员没感觉？很正常，没经过这方面训练，又没天赋自己发现甚至重新发明一遍。不过看着一票程序员连 syntax 和 grammar 都没概念区分清楚（汉语翻译错位又更拉胯），我只是觉得这种活还是别指望只会做程序员的人干比较好，就不太想多指望些啥了。（也不是专业搞这个的就一定像样，还有 doi: 10.1023/a:1007720632734 这种在关键最终结论上掉民科级别链子却能过 peer review 的。）
当然也不是没基因干这个的就干不出表面像样到能吸引到更随大流的程序员的东西。像正常来讲工程师日常多少都得看技术规范，结果 TS 和 Rust 连个 up-to-date 的 spec 都难（没）产（有），用户基本上照样给啥吃啥，说明就没几个有当工程师的素质（暴论）。

而当这种素质稀薄到一定程度上，所谓语言工具论也就不奇怪了。这个看法虽然明摆着 low ，但实际上也就仅仅是更 low 。OP 所谓的“喜欢造新语言”的欧美很多那啥啥，其实本质上也是挺 low 的（不算暴论）。
当然我也不是啥反思怪，要人反省为什么看不到 low 。只需反思一下，为什么更 low 的理解仍然会有土壤，为什么 OP 自己不会**想着亲自去怒怼“普遍认为语言只是工具”而只是拿这个构成这楼的标题**，那么就解答了一半的问题。

另一半问题，就 PL 方面特别菜（得不应当理所当然）的问题，展开一点。
所谓编程风格是个啥，只会编程的，大多自己就说不清楚。成天 FPFP 的，有几个人知道 FLP 是啥么？
理由也很简单，编程跟设计语言和确定所谓的风格本来就是不同的领域。只会编程的，大多甚至连可编程性的来源都没怎么关心过，又经常被坑而对这个感（无）到（能）不（狂）满（怒），所以就菜鸡互啄了。
以讹传讹多了，到 FP 是个什么东西都难以对只会编程的用户解释清楚了（虽然我不是没试图解释过，非重点链接懒得放了）。APL 党吹的 pointless 当作 FLP 可能值得单独批判一番，因为那是真的更纯粹的“风格”。什么风格呢？嗯，好比 combinatory logic ，相比 lambda calculus ，妥妥的**低级语言**，因为刻意挖掉了抽象(lambda abstraction)顺带干掉了健全的变量。对此缺乏直观认识的，可以了解一下 unlambda 。
设计这些抽风语言的原始形式基本都算不上纯粹的程序员；其中一些人还特别喜欢推销。所以在让人不痛快的语言恶心人的能力上，程序员不用有啥优越感的。
这里的共同点是，不管是不是程序员，大多数语言设计者光是认知的储备上，真的对设计实用语言的 pure PL 菜得很。程序员做不大到的是连带把 PLT 也搞得一团糟，搞的 model 根本理论联系不到实际，于是俩菜坛子分裂的问题就越来越没得解决了，以至让大多数人习惯了。（一堆著名 PL 壬的例子略。）
菜惯了导致两个相对直接的后果：一个是经常有用户发现现有的语言用不舒服；另一方面是经常有用户认为这玩意儿看来没什么可行性包袱，先上了再说。然鹅实际的维护工作做得下来的有几个？更别提考虑对业界有啥影响了。
所以一般人注意到满天飞的“新”语言，说好听点是 DSL ，说直白点半成品都不是。嗯，顺带杀死了路人用户温故知新的能力。
其实搞语言玩玩也不是不行，培养兴趣也是重要的嘛。但是要正视对这个世界的影响，脱离做半成品电子垃圾的低级趣味是一个社会的人补完自己的必由之路。
Haskell 那种筛掉小鬼以后的理论家都整天只会吹 equational reasoning 的，会遇到性能问题就直球菜鸡 QoI 不行就是了。比起这个是更喜欢拿 GHC 的 seq magic 直球来黑默认 equational reasoning 和 lazy 这个核心设计思路本身（比起爆杀 monad 乃至 applicative 小鬼起来爽多了），然后再嘲讽 PFP 没 identity 倒是整活 levity 之类的破烂。不过这个文献跨度比较大我不想每次都展开。

至于能力甚至都没入门低级趣味的门槛的，我暂时不想多评价。

@majula 最近？

WSL 本来就是 WSA 搞黄了半路出家的半成品废物利用的成果。
后来加了坨 Hyper-V 的叫 WSL2 ，这个就改叫 WSL1 罢了。
现在又想起来觉得是时候搞了呗。
至于 WP 就算了吧，怕是得铺路到下个世纪再说。

操作系统不就是一个带 HAL 的大号运行时么。
OP 举例的东西不大够，因为 HAL 不算 Web 内部的东西。W3C 的人智商加起来在这方面也不大够用；我预期几十年内基本都会这样。
另外 Web 其实是指网络，所以其实当操作系统也是一整坨分布式操作系统。
至于谁有钱有空能烧到这玩意儿能实用，就天知道咯。

因为太菜，低级复制一大坨，以至于技术上没法当做一种。
当然要扯财产权之类的问题另说。