Tag: 编程

Without writing, you are reduced to a finite automaton. With writing you have the extraordinary power of a Turing machine.

—— Manuel Blum, a Turing Award winner

这句话延展一下，就是：不创造，你就是有限状态机。只有创造，才能让你拥有图灵机的神力。

第三个网站 Read PDF Aloud 上线了。

12 月 14 日开工，1 月 1 日凌晨上线第一版，到今天把已知的 bug 和不完善的地方全部修改完，一共花了大半个月的时间，是我工期最长的一个站。

Read PDF Aloud 核心的功能和交互相比之前的网站都要复杂，所以踩了不少坑，都是经验不足导致的。

程序设计上，这次核心的交互逻辑是用面向对象的方式完成。

svelte 的状态管理方式天然适配面向对象范式，官网文档上也专门就 runes 在 class 内的使用做了介绍。这次真正使用面向对象，我也感受到了面向对象的优势，心智负担低，越写越顺手。

但这一切建立在对象设计合理的基础上。如果一开始规划有问题，后面少不了返工。我这次就经历了推到重来的过程。

第二个坑是 CloudFlare Workers。这次的涉及到 PDF 的文字提取和 TTS Api 的调用，所以需要一些简单的后端功能。我最初为 PDF 解析和 TTS Api 调用编写了相应的后端接口，都非常简单。

但是，在我第一次部署到 Worker 后，我就遇到了后端报错。一开始我还以为是我部署方式不对，后来我又怀疑是不是我用的库不适配 Worker 环境。

看完 Worker 的后台日志以后，我才发现，错误原因是 Error 1102: Worker exceeded resource limits。

简单来说，就是 Worker 对单次请求消耗的 cpu 时间有限制。免费版是 10ms，付费版是 30s。一些计算量比较大的任务，难免会占用更多 cpu 时间。当时我心都凉了，一度考虑要不要租个服务器。我还上网查了一下，发现踩到这个坑的，不止我一个。

后来理智说服了我，在没有赚钱的情况下，不能乱花钱。那就只能让用户体谅一下我的难处了，把 PDF 解析放在了用户的浏览器里。

剩下的坑就是一些交互设计上的问题了。

我一直觉得写 ui 最浪费时间，因为很容易陷入细节调试的地狱，我就看这个设计不顺眼，但是又不知道怎么改好，想太久，时间就白白浪费了。

之前做的网站交互都比较简单，这个问题不明显。这次的交互方式更复杂，尤其是阅读器的界面，我边想边写边改，来来回回拉扯了两天。昨天上线，发现交互有问题，又改了一天。现在这版算是没有大毛病了。

编程好难啊。

Ai 让我编程的乐趣消失了，至少消失了一部分。

编程的乐趣和打游戏一样，是绞尽脑汁、反复尝试，直到找到解法的那一刻完成压力的释放。

Ai 现在就和游戏里的「金手指」一样。在绝大多数情况下，脑汁不会被「绞尽」，把思路告诉 Ai，它能直接平推过去，大差不差。没有压力，就不存在压力释放时的多巴胺分泌，整个体验变得索然无味。

人类总是喜欢在显而易见的事情上追求完美。

我每次写 UI 的时候，都十分折磨，因为我总觉得不好看。写一点，改一点，再写，再改。一天下来什么进展都没有，一直在原地打转。

但我写后端代码时基本没遇见过这样的问题。

所谓金玉其外，败絮其中，就是这么来的。

用来用去还是 VS Code 好用……

在写前端项目的时候，Zed 的内存开销相比 VS Code 没有太大优势，但是 VS Code 的插件比 Zed 更好用，即便是同款插件，VS Code 版本的似乎也更智能一点。譬如 Svelte 的组件导入，VS Code 版本的 Svelte LSP 插件的补全提示很快能显示出来，而 Zed 版本几乎只能靠 AI 的 inline hint，插件好像就不会显示组件的补全。

另外 VS Code 的动画会更顺滑一点，不知道是动画还是字体效果的缘故。

因为 vitest 只能用 node 运行，所以 不得不吧 easy-office-2 的里所有直接调用 Bun Api 的代码全部改成兼容 Node Api 的形式。

质疑 node，理解 node，使用 node，但是我依然讨厌 node。

最近清理了一波电脑。浏览器用 Helium 替代了原来的 Chrome。代码编辑器用 Zed 替代了 VSCode。输入法从 Rime 换回了 macOS 原生的拼音输入法。

关于 Zed，我已经在[2025-10-22_20-34-49|我支持用 Rust 重写世间万物提到]过了。这两天实际编码体验非常好，不过我写的毕竟还是 JS / TS，工具链全部基于 Node，内存开销并不低。Zed 本身的内存占用也不低，启动倒很快。希望 Rust 社区继续发光发热，继续改造 JS / TS 工具链，把 Node 干掉。说到这里我又馋 deno 了……

Helium 和 macOS 原生拼音输入法的体验都不错。Helium 本身是基于ungoogled-chromium，使用体验和 Chrome 差不多，但没有 Google 服务的捆绑，开销更低。

至于 Rime，更像是一段插曲。当初是因为 macOS 原生拼音输入法有 Bug，会导致莫名其妙的死机，我才换到 Rime 的。现在 macOS 原生拼音输入法已经稳定了很多，Rime 高度个性化的优势在我这里也不算优势，从零开始培养一个惯用的输入法对我来说也很麻烦。除了不喜欢 Tahoe 的液态玻璃效果，我对 macOS 原生拼音输入法没有任何不满。

再次尝试使用 Zed。

2 年前刚学编程那会体验了一下 Zed，因为生态不完善没有继续使用。现在 Zed 写 Svelte 已经没啥问题了，也支持 GitHub Copilot。基于 Rust 的编辑器，运行速度没得挑。

原本以为没有 Foam 插件，处理我的 markdown 笔记会不方便，结果发现 Zed 有类似的 markdown oxide 插件，功能类似。

现在编码体验非常流畅，舒服了。

Rust 大法好。我支持用 Rust 重写世间万物。JS / TS 生态就应该用 Rust 重写，把 language server 什么的都重写了。现在电脑里剩下的 node 进程基本都是 language server。

看到一个有趣的类比，将联想记忆法比作数据库建索引，本质上是拿空间换时间，在一个缓冲区里放更多数据，以此减少常∫用数据的索引速度。

Anton Putra在 YouTube 上发了一条视频，对比了 FastAPI (Python) 和 Node.js 的服务端性能表现。第一轮是测试单纯的 Get 请求，第二轮是测试 PostgreSQL 数据库的写入。两轮测试下来，Python 的综合性能表现差不多是 Node.js 的 1/10。

一般来讲服务端的性能瓶颈都在数据库 IO，很少会遇到 CPU 瓶颈。Anton Putra 测试过不少语言和服务端框架，Python 是为数不多能在测试中段就能撞上 CPU 性能墙的。而且撞墙以后也没有恢复，后半段被锁死在 50% 的 CPU usage 上跑完了全程，也不知道为什么。

FastAPI 已经是 Python 生态内性能比较好的框架了，我真不敢想 Django 这种老乌龟得慢成什么样。没有 jit，再加上 gil 的限制，Python 的性能真的……配不上它今天的江湖地位。

最关键的是，Node.js 在 JavaScript 生态内的性能也不突出，甚至可以说是比较拉胯的……