@fiveelementgid 你取得有关部门许可了吗？你背后是谁，发这些想干什么？你想颠覆什么、破坏什么？

https://i.loli.net/2021/02/04/94hQRUBHKbsXVra.png

@echo1937 其实要真是新 ISA，还得折腾 gcc, glibc, kernel 一套全家桶……
然后人家 ARM 能跑 Windows，你不行

第三，你有本事做 ISA，你有本事做 uArch，你有本事做 Rosetta 么？

第二，uArch 也不是你想的这么简单的事情。
高通在十年前是自己的微架构，但是被 64 位的 A7 偷袭了，来不及搞新架构，就公版架构套了一个出来，你猜那代产品叫啥？就是大名鼎鼎的骁龙 810
后来 820 又整出了个新架构，但是表现一般，再往后就接着用公版了
三星的自研架构前段时间刚黄。就算在的时候，貌似也是骁龙版比猎户座版更好，你猜是为啥……
海思也是小改公版
联发科更逗，公版做的都不算太好
你想想为啥手机处理器除了苹果之外没人做 uArch

第一，ISA 不是你想的这么简单的事情
你可以去了解下最近的新星 RISC-V，然后思考下，为啥这么多资源投在里面，这东西进展还是这么慢
其实 WebAssembly，以及很多标准化的东西都是类似的道理

xmonad 其实有做 window decoration 的插件…… 不过貌似是单独创建的窗口
还有个鼠标拖动交换窗口的插件，再加个 bar 的插件切换 workspace，就可以脱离键盘使用了……

多线程写入，结果就是写入的数据不可靠，不是直接给你报错。
只有你再使用写入的数据时才会把问题暴露出来，而在实际程序中很难知道是谁什么时候写入的数据，这是并发错误难调试的原因之一，报错的点不一定是 data race 发生的点。

有时候也会故意这么做，性能会好一些，

@agagega 很不幸"基于正则的语法高亮"在我这也是要淘汰的 ...

我举两个类似的例子：

引用 https://v2ex.com/t/612874#r_8089400 这里面的：
> LLVM 一开始用了以 camelcase 为主的命名方案，具体来说是类型名，变量名（包括局部变量和成员变量），用 UpperCamelCase，函数名是 lowerCamelCase 。
> 但是后来发现一个问题，比如我有一个变量的类型是 MemorySSAUpdater，那么按照命名规范，我不能把它命名成 MemorySSAUpdater，因为会和类型名冲突，现在的解决方案是取首字母 acronym 命名成 MSSAU 。这种情况在整个仓库里十分广泛： https://github.com/llvm/llvm-project/blob/734c74ba14be0f4421ccd9f720e5b9309248e0f7/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp#L709 感受一下
> 但是这种命名多了就会十分奇怪，看代码必须先要熟悉这些奇怪的缩写才能看得下去

> 于是现在有个 proposal 就是把变量命名从 UpperCamelCase 变成 lowerCamelCase，这样我就直接命名成 memorySSAUpdater 就行了： https://llvm.org/docs/Proposals/VariableNames.html

当时这个事在邮件列表里面吵了半天 ...

同一帖子上一楼提到，一些函数式编程语言强制要求某些结构使用特定的命名规范，比如在 OCaml 中，constructor 和 module 的名称必须以大写开头，而 Haskell 中类型和 constructor 必须以大写开头。刚开始学的时候感觉有点奇怪不过没太在意，后来也就习惯了。
但是后来我自己写语言抄 OCaml 的时候就发现问题了，通过这种语言设计上的小动作，编译器实际省下了很多工作——正则一匹配就知道这个标识符到底是个值还是个 module，同样是命名空间的访问，value.field 肯定是访问一个 record 中的值，Module.value 肯定是访问模块中的值，Module.Submodule.value.field 肯定是嵌套模块访问 + record 访问。
而类似的问题在 C++ 中的解决方案是引入两种语法结构： "::" 用于静态命名空间的访问，"." 用于实例命名空间的访问。
现在我自己要解决这个问题，要么抄 OCaml 的，把命名规范搞得不像个“正常语言”，要么学 C++ 的，多占几个符号，多加几条规则，还有一种方法是我 parser 开洞，不通过任何语法层级的东西来 disambiguate，不过那样 parser 跟 C++ 的就差不多屎了。
现在我已经放弃在文本层面解决这个问题了 ...

@Mithril 哪个蠢驴
是瑞典的那个么，那个主要应该是祖宗之法不可变的问题
还是波兰的那个，那个主要应该是管理的问题
这种优化手段应该对这种大量重复元素的场景是比较适合的，其他的效果不一定好，期待后续文章。

另外还有一个思路是分流，因为一般意义上的“群”从概念上来说是一群人围绕某个主题集合在一起（这种事情貌似是要有关部门批准的？），但是由于群不是职业性的，所以一般”人”要比”主题”更突出。到最后就变成二选一，要么人要么主题，但是人明显是最根本的，所以选择“主题”的，一般我们称为”死了”。
Discord 在这方面做得就不错，Discord 中的群是”人+弱主题”，在群中再细分”频道”(貌似是这么叫的)，也就是强主题，但是同一个群中的频道共享一群人。一般 IM 是群=>聊天窗口二级 UI，Discord 是群=>频道=>聊天窗口三级。比如搞一个 V2EX 群，就可以有 C++频道，Java 频道，找工作频道 etc. 这样缺点是频道多了之后一个个关注会比较费劲，但是几乎所有群都会有一个”offtopic”频道。这样吹水也不误，正事也不误。存人失地，人地皆存。
（频道多的自然解决方法也很简单，就是搞一个聚合频道，然后你会发现这特么不就是 V2EX 的 IM 版么……）

如果你想做到”干货比例大概在 70%以上”，同时还想有人说话的话，至少有两种方式：第一是做梦，第二是研究时间机器——总之就是想办法穿越到另外一个世界去
如果想做到干货比例 60%以上的话，在本世界线倒是可能的——从把每一个撤回消息的人禁言一天开始

这个问题和面试是一样的

面试的时候你先大吹一通，就类似：
> 珊瑚海配色和牛油果配色 ... 蓝牙

然后看能不能把面试官唬住，唬得住 50k，唬不住 5k

VSCode 有正常，给编辑器写小插件的成本一般远小于给 IDE 写

我猜用 flex 和 bison 的一般都在用 vim/emacs ...

看图感觉是桌面左上部分出现了一个透明的窗口把事件挡住了的样子……

感觉可能是表格组件为了获取某些参数会做这么一个临时设置，拿到之后就会恢复原来的设置，但是这个过程出 bug 了
应该可以以 body 的 overflow 样式变化事件设置断点做做文章

倒是学学 C++可能对”创造编程语言”有更实际的帮助