I think it’s useful to distinguish compilation whose target is another language that was originally intended to be human-readable (transpilation) from compilation to a form intended exclusively for machines (compilation to machine code or bytecode).
Compilation is the act of going from one language to another, machine or not. This is what I was taught at least. "Machine code" or "bytecode" holds no special distinction.
In this article's case, there a reasonable exception to made when JavaScript is being "compiled" into JavaScript itself. For that, I don't know what the term is (or if there even is one).
> [...] there a reasonable exception to made when JavaScript is being "compiled" into JavaScript itself. For that, I don't know what the term is (or if there even is one).
Well, given
trans : (+ acc.) across.
and
ipse ipsa ipsum : himself, herself, itself.
I propose we call that ipsumpilation ;)
More seriously though if the input is js and the output is js, and it’s not different versions of the language — e.g. es6 -> es5 (because imo that qualifies as different languages) — I’d call it an optimizer or a packer depending on what it does.
"Transcompiler" was the older term for assembly -> assembly.
I don't think it's too much of a stretch to shorten that to "transpiler". I think people hate the term because they associate it with JavaScript hipsters who have no sense of CS history and presume they've invented something new. The same as how you cringe when someone refers to the "#" character as "hashtag".
But "transpiler" is a useful term. We're in a world now where source-to-source compilers are much more prevalent than they were ten years ago, and there are real workflow differences between working with a compiler that targets a low-level language versus a high-level one. Things like how you debug the output are very different.
> there are real workflow differences between working with a compiler that targets a low-level language versus a high-level one. Things like how you debug the output are very different.
Like what? When I've had to debug GCC, I just dumped out the GIMPLE et al.; what do you do differently with a 'transpiler'?
Sorry, "debug the output" was a really confusing way to say what I meant. What I meant was users will want to debug their code, and the way they do that is often affected by what their code is compiled to.
With a transpiler, it's fairly common to actually debug using the generated output. That pushes many transpilers to place a premium on readable output that structurally resembles the original source code, sometimes at the expense of performance or code size.
Other times, users will rely on things like source maps in browsers. That gives more flexibility to the transpiler author but can make user's debugging experience weirder because things like single-stepping can get fuzzy when a "step" in their source program may correspond to something very different in the transpiled output.
In compilers to lower-level languages (machine code, bytecode, etc.) there is a strong implication that most users can't debug the output, so the compilation pipeline and tools are obligated to have pretty sophisticated debugging support.
In other words, different tools, priorities, constraints, etc. Having a separate word to help tease these apart seems useful to me.
All of that I view more as examples of how immature the tooling is on the frontend, rather than an inherent distinction between source->source and source->machine compilation.
I remember crappy C toolchains that only gave you a .map file for debugging. It was just table of where the linker put the symbols from the intermediate objects. Hell, there were a lot of really crappy C compilers then that looked way more like babel than gcc. They basically just parsed into an AST and walked it to spit out asm, hardly doing any optimizations.
Admittedly translator and transcompiler where probably the more popular terms, but the term transpiler can definitely be found in the literature of the 80's. I know last time this came up someone posted a link to an article from the 70s using the term in that context.
Personally, I think of transpilation as a subset of compilation. So a transpiler is also a compiler, and a compiler that has a readable language backend can do transpilation, which is a type of compilation.
u/masklinn still asks a good question though: there are tools that act on the source code for both "compilation" and "transpilation" (eg Kotlin), depending on the target platform. They do not distinguish, why should we?
For the same reasons you might ever want a more specific term?
What about assemblers or disassemblers? Given a suitably broad definition of compiler that includes transpilers, are they not also included? Wouldn't the same arguments apply?
> For the same reasons you might ever want a more specific term?
I asked why you might want this here and there's been no answer yet. Having a term for something you don't need or want to know isn't actually useful.
> What about assemblers or disassemblers? Given a suitably broad definition of compiler that includes transpilers, are they not also included? Wouldn't the same arguments apply?
Because these are actually useful qualifier, in the same way that "a C compiler" is a useful qualifier.
