🎯 讨论背景

这篇帖子是在比较 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 工具未必是最优解。

[来源1] [来源2] [来源3]

MCPB 发布形态与代码可见性

有人一开始搞不清 MCPB 是什么，后来才发现它是给 MCP server 用的安装/分发 bundle，而 Claude Desktop 还支持这种形式。这个设计被认为很吸引人，因为 MCPB 会提供 Node runtime，最终应用里可能只剩自己的代码，体积甚至能压到约 1MB。也有人指出 MCPB 还能跑外部进程，因此把 Java 版本编译成 GraalVM 原生二进制再塞进去也行。另一方面，仓库里几乎看不到真正的 TypeScript 代码，关键逻辑被放在 release 里的 exe 中，这让项目显得更像“壳”而不是完整源码仓库。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

Office 文档库与 stdlib 辩论

围绕 DOCX 处理，评论认为 zip 和 XML 进入 stdlib 并不奇怪，但更实用的路径可能是直接用 Java 生态里的 DocumentFormat.OpenXml / Open XML SDK 来处理 DOCX、XLSX、PPTX。也有人补充 Apache POI（Java 的 Office 文档库）本来就是专门干这个的，未必需要自己手写 XML 解析。争论焦点随后转向 stdlib 的边界：太瘦会把复杂度推给依赖管理，最后变成 NPM 那种“hello world 都要拉一堆包”的局面，但库全塞进核心也会让运行时变重。

[来源1] [来源2] [来源3] [来源4]

Ruby 生态的类型、文档与代码质量争议

最长的一条评论几乎是在反驳原文对 Ruby 的不满：缺 .each、忘 .children、到处冒出 nil，更像是代码结构混乱和习惯性偷懒，而不是语言本身必然导致的问题。它强调 nil 可以靠更好的方法拆分和检查来处理，不必把 typing 当成补救一切的万能药。评论同时把矛头指向 Ruby 生态的文档质量，提到 rack、opal、ruby-wasm、ruby_llm-mcp 的字段改名和 rubyzip 损坏 DOCX 的 bug，认为“代码自解释”常常只是糟糕工程的借口，甚至怀疑整段故事像 AI 生成的。

[来源1]

📚 术语解释

MCPB: 一种给 MCP server 用的打包/安装 bundle，便于在 Claude Desktop 等环境里分发和启动工具。

GraalVM Native Image: 把 Java/Kotlin 等程序编译成原生可执行文件的技术，通常能缩短启动时间、减少运行时依赖。

Smalltalk: 早期面向对象语言，很多现代语言里的 lambda、map、filter 等风格都能追溯到它。