加载失败
争论源自一篇题为“Transpiler, a Meaningless Word”的文章，主张不必用“transpiler”这个词。Hacker News 评论用工程与语义例子来反驳或支持这一观点，引用了具体工具与史实（如 BabelJS、Haxe、TypeScript→JavaScript、Nim→C、GCC 输出 GNU 汇编、clang -S）来讨论何时把输出称为“源码”有意义。争议既涉及编译器架构差异（直接生成汇编 vs 生成 AST 并输出源码）、输出是否可读与互操作性，又牵涉到语言习惯与分类学视角（Lumpers vs Splitters）以及“compile/link”一类英语词源混淆。评论者既有实务工程师视角，也援引教材定义来检验术语的精确度与实用性。
支持者认为“transpiler”是编译器（compiler）的一种有用子分类，用来指把一种源码翻译成另一种人类可读且抽象层次相近的源码。评论里列举了具体例子（TypeScript→JavaScript、Nim→C）并强调目标语言的可读性、互操作性与宿主语言限制会影响工程决策。技术上，他们指出在编译器架构上“直接输出汇编/三地址指令”与“生成高层 AST（抽象语法树）再输出源码”是不同的实现路径，因而命名可传递有价值的信息。总体观点是特定命名能让使用者与维护者更快预期输出行为与集成成本，而非纯粹语义重复。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
反对者认为按传统定义，compiler 已经涵盖“把代码翻译为语义等价的另一种语言”的行为，因此额外的“transpiler”一词并不必要。有人引用教材/定义（例如 PLAI 的编译器定义）并指出很多所谓“转译”到 C 或 JavaScript 的输出实际上非常非典型（unidiomatic），不具备对人类有用的可读性，从而削弱了“输出源码即为转译器”的论据。还有编译器实现者表示实现方式与目标语言无关——写编译器时无论目标是汇编、C 或 JS，工作流程相似，因此该词对实现者没有实际指导意义。他们认为若术语不传递可操作信息，就是模糊而无用的细分。
有评论用分类学框架“Lumpers vs Splitters”来解释为何有人觉得额外词汇多余：合并者倾向用更宽泛的类别，而切分者强调细粒度差异。反对的论点则指出这并非纯粹主观争论，而是存在可被揭示的客观分类依据——例如把“transpiler”看作 compiler 的专门子类，或把“embedding”与“vector”区分开来。另有评论举历史例子（如“computer”一词曾被用于非图灵完备的模拟器械）并提醒混淆往往来自于隐含形容词（programmable、digital、electronic 等）没有被明说，从而让分类看似矛盾。总体这组观点把争论定位为语言学/认识论的分歧：是细分能揭示领域结构，还是合并更节省词汇。
多条评论用历史与实例来校验术语有效性：有人指出 BabelJS 常被称为早期 JavaScript ‘transpiler’，但 Haxe（一个多目标编程语言/工具链）更早提供类似概念，说明术语并非新生；GCC 会输出文本 GNU 汇编，历史上许多操作系统与游戏是直接用汇编写成，表明“源码输出”并不总是不可读或不实用。讨论还涉及‘compile’ 一词在英语中的词源（有“汇编、集合”含义）以及链接（linking）与加载的命名混淆，指出编译器运行时会把外部例程拼接进输出。学术教材与工具（如 clang -S、GCC 输出）被用作检验点来说明什么时候称呼为“transpiler”合适或会误导。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
transpiler（转译器）: 把一种编程语言的源代码转换为另一种源代码的工具，通常保持大致相同抽象层次与可读性（例如 TypeScript→JavaScript、Nim→C），常被视为 compiler 的子类。
compiler（编译器）: 更广义的程序，把源代码翻译为语义等价的另一种表示（机器码、字节码或其他语言）；不同子类包含本地编译器、交叉编译器、字节码编译器与所谓的 transpiler。
AST（Abstract Syntax Tree，抽象语法树）: 编译器内部对源代码语法结构的树形表示，用于进行高层次转换与优化；生成 AST 再输出源码与直接生成汇编在实现上有显著差别。
assembly（汇编语言）: 一种低级的人类可读机器指令表示（例如 GNU 汇编）；编译器可以输出汇编文本，历史上许多程序直接以汇编实现。
Lumpers vs Splitters（合并者 vs 切分者）: 来自分类学的思维模型，用来说明有人倾向用更宽泛类别（合并）而有人倾向细分专门术语（切分），常被用来解释对术语冗余或细化的分歧。