会议纪要 / 围绕编辑体验设计编程语言 / 向后兼容的内容站构建系统
今早来到实验室发现昨晚Windows自动更新并重启了。
KB5044284终于装上了。
昨晚写得匆忙，查缺补漏一下。
本来还跃跃欲试要把DSLabs继续往下写lab3，想想记下来要干的活，想想报销的手续，默默打开这个老老实实写了起来。
昨天写了跟ℒ开会讨论的项目，没有写接下来的安排。
Vispo倒是没有什么后续，还是试着写写代码，然后看看能不能照着代码起草一下我们究竟是想干嘛。我表示这玩意实在找不着感觉还是先转入不活跃状态吧，ℒ表示可。
然后就是昨天写到的三个项目，隔壁老板项目——从今起称为DHT验证项目，Cover，和RPC模型检查。
我问，这仨只要任意一个做个大概就可以TP了吗？ℒ表示可。
我忽然意识到了什么，问，如果做的是Cover，那是不是还要再做一个自己的点子？ℒ表示如果对他原来的点子进行了大幅改动也可以不用再做了。
我有些过意不去，提出Cover的新点子感觉适合纯吹水，要不去HotOS投个vision paper吧。ℒ表示可。我又问vision paper能往TP里写吗，ℒ表示可。
我当时的意思是把它以vision paper快速扔出去然后再做一个项目，怎么现在回想起来感觉像是要糊弄成一篇vision paper然后就直接TP了的意思……
DHT验证项目思想境界很高，怎么看都是得往OSDI/SOSP送的东西。
RPC模型检查倒是可以算是适合SIGCOMM，但是想赶上的话有难度。
于是我表示卡皮巴拉要争取在12月到来之前交付（我参与的部分）。然后新的项目在年底之前也要有所推进。
然后想起来还有一个正投着的Entropy，12月要转回来了后面还得往SIGCOMM送。
我将从现在开始一刻不停努力干活到明年五月。
—— Cowsay，2024.11.12
写编译器的想法属于是老生常谈了。哪怕是为IDE优化设计也不是什么新想法了。
当今的（流行的）编程语言，哪怕是10年代后的最新一代，在设计的时候也没有把IDE放在眼里。都是先做了个批处理的基础设计，然后再视能力（和对社区的态度）搞点编辑器插件来起到「填缝」式的功能。
编译器多少是没把编辑过程中的动态信息传递需求放在眼里的。插件可怜巴巴地得不到什么正式的支持，要重复实现很多编译器的逻辑（比如解析源码文本），然后还得用心揣摩编译器的心思避免行为不一致。
另外一方面，像Rust这种写一整天编译一次的语言，编辑器才是绝大多数时间里程序员打交道的对象，而编译器才是那个来填缝的。
下一代的编程语言应该把编辑反馈作为最优先的设计考量。编辑器的解析不再是某种浅尝辄止/「best effort」的增值业务，而是实打实的「编译发生的地方」。LSP进程中就应该包含所有的编译产物（起码是平台无关中间表示），代码写好以后的要做的不再是一个从头开始的端到端编译，而是一个「导出编译产物」操作，就像剪视频剪好了以后导出渲染一样。
朝这个方向再往下走一步就是结构化编程。不要再写纯文本啦直接拖拖拽拽搭积木吧。彻底解决花括号换不换行的圣战——把花括号直接干掉了。彻底解决模块/编译单元与文件系统结构的映射关系的圣战——把文件系统侧的结构也直接干掉了。等等之类的。
这个项目总之现在不做，因为要自己补足的设计太多了。就算现在真的有闲心摸鱼，也先做下面这个。
我之前就搞过一次自创静态内容站的构建工具了。东西能用所以可以说效果还可以。后来不做了也不是什么技术问题，只是见色起意然后又回来投敌了而已。
然而我又攒了一些自己的客制化需求，稍微列举一下。
时间戳。 现在用的这个主题给Jekyll加了个钩子从git提交中读取最后更新时间，已经挺让我满意的了。然而我最近注意到它没有把时区信息转递到页面中，最终传递的是「根据原时间戳中的时区信息转化的UNIX时间戳」，然后显示的是浏览器当地时区下的这一UNIX时间戳。
我想要带时区的时间戳，这可以反映出我是世界上的哪里，在一天中的什么时候写的东西。不知道这是不是Jekyll的限制。估计是的。
文化遗产（legacy）。 总是想把以前的内容站里写过的东西迁移到这边，但是又希望把它们用一些特定的方式展示出来。比如在时间轴的归档页面，还是希望清晰地展示「开幕致辞」才是第一篇内容，再之前的都是「史前」内容（也许可以分出各个不同的史前时期）。
主页。 我不喜欢在主页上纯倒序排列文章。想在主页上放一些统计信息，全站共有多少字，全部读下来要多久，每天平均写了多少字，等等之类的。
etc.也是一个很不好（简短）翻译的东西
样式。 大部分样式需求都可以通过定制主题来实现，但是有一个东西比较麻烦。我想（像LaTeX一样）把强调内容给显示成楷体。之前研究了一阵CSS，然后感觉得构建工具侧做点配合才比较好做。
标签。 目前为止所有的内容都是没打标签的，因为懒。我想搞一套自动化提取标签的功能，也许要引入一点大模型的帮助。
检查点。 其实是一个针对重复的文件名的通用需求，只是目前我重复的文件名都是检查点日志。这个主题默认的网页链接是只有文件名（去掉日期）的，就会导致这些检查点日志都会冲突在同一个{网站地址}/checkpoint.html链接下。我手动给它们的链接都加了日期，但是只是权宜之计。
摘抄。 开幕致辞中就提到的，为文章中的小段文字专门渲染一个页面出来。
还有点什么怎么都想不起来，大概是修bug方面的，但是看了看网站也没看出什么bug来。
跟上次「（工作量）最小化可用实现」的目标不同，这次的计划是完整向后兼容。
当然，不是说要自己做个Jekyll出来。比如主题就定死我现在用的这个就可以了。是说拿着这个仓库里面的这些文件，用自己的构建系统生成出来的网站跟Jekyll生成出来的完全一样。
我对自己的业余项目总是做不下去的最新理解
最重要的是找到一个合理的规则，不能太宽松也不能太严格。我没有hold住太宽松/灵活规则的水平。比如上面的编程语言项目，就会需要我自己做太多设计，我就会因为设计得不够好而导致项目做不下去。还是得有点什么来约束我的行为，仿照已知的行得通的工作就是很好的选择。
至于太严格的目标为什么不行，我这会儿给忘了。可能就是工作量太大吧。
总结起来，「极简XXX」是个合理的思路，但是不能只是极简，得是在明确了最终效果的情况下，找一个工作量最少的方式把它给糊弄出来。也许这样我就能干的下去了。
总之，先把Jekyll给平替掉，然后把自己想要的这些功能补上去。