"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.
Transpiler?
Transpiler has been around as a term in CS for a while now. Initially it was used for compilers that compiled from one dialect of assembly to another.