这篇帖子是在比较 Ruby、Java 和 TypeScript 处理 DOCX（Word 文档的 XML/ZIP 容器格式）时的体验，目标是做一个面向 Cowork/Claude 的插件。评论把话题拉到了 MCPB（MCP server 的安装/分发 bundle）和 Claude Desktop（Anthropic 的桌面客户端）上，因为这类打包方式决定了插件如何交付、体积多大、能否带上 Node runtime。另一条重要背景是 Java 生态的替代方案：GraalVM（JVM 生态里的原生编译方案）、jpackage（Java 打包工具）、Apache POI（Office 文档库）和 Microsoft 的 Open XML SDK 都被拿来对比。讨论最后又回到 Ruby 生态常见争议：静态类型工具 Sorbet、文档质量、nil 处理、以及 rubyzip 之类库在处理 DOCX 时可能出现的兼容性问题。
评论先把 Ruby、Java、TypeScript 的选择扩展到了 Kotlin，有人认为 Kotlin 很像“带类型的 Ruby”，同样是偏 OO，但会在合适的地方加入不少 FP 特性。随后又把这类特性追溯到 Smalltalk，指出 lambda、map、filter 之类并不是新东西，只是后来很多语言丢掉了又补回来。另一条线讨论 GraalVM 原生编译和 jpackage：原生二进制可以很小、启动很快，但编译耗时明显更长；对 CLI 工具很香，对 GUI 工具未必是最优解。
有人一开始搞不清 MCPB 是什么，后来才发现它是给 MCP server 用的安装/分发 bundle，而 Claude Desktop 还支持这种形式。这个设计被认为很吸引人，因为 MCPB 会提供 Node runtime，最终应用里可能只剩自己的代码，体积甚至能压到约 1MB。也有人指出 MCPB 还能跑外部进程，因此把 Java 版本编译成 GraalVM 原生二进制再塞进去也行。另一方面，仓库里几乎看不到真正的 TypeScript 代码，关键逻辑被放在 release 里的 exe 中，这让项目显得更像“壳”而不是完整源码仓库。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
围绕 DOCX 处理，评论认为 zip 和 XML 进入 stdlib 并不奇怪，但更实用的路径可能是直接用 Java 生态里的 DocumentFormat.OpenXml / Open XML SDK 来处理 DOCX、XLSX、PPTX。也有人补充 Apache POI（Java 的 Office 文档库）本来就是专门干这个的，未必需要自己手写 XML 解析。争论焦点随后转向 stdlib 的边界：太瘦会把复杂度推给依赖管理，最后变成 NPM 那种“hello world 都要拉一堆包”的局面，但库全塞进核心也会让运行时变重。
最长的一条评论几乎是在反驳原文对 Ruby 的不满：缺 .each、忘 .children、到处冒出 nil，更像是代码结构混乱和习惯性偷懒，而不是语言本身必然导致的问题。它强调 nil 可以靠更好的方法拆分和检查来处理，不必把 typing 当成补救一切的万能药。评论同时把矛头指向 Ruby 生态的文档质量，提到 rack、opal、ruby-wasm、ruby_llm-mcp 的字段改名和 rubyzip 损坏 DOCX 的 bug，认为“代码自解释”常常只是糟糕工程的借口，甚至怀疑整段故事像 AI 生成的。
MCPB: 一种给 MCP server 用的打包/安装 bundle，便于在 Claude Desktop 等环境里分发和启动工具。
GraalVM Native Image: 把 Java/Kotlin 等程序编译成原生可执行文件的技术，通常能缩短启动时间、减少运行时依赖。
Smalltalk: 早期面向对象语言，很多现代语言里的 lambda、map、filter 等风格都能追溯到它。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。