I agree with you that we've lost though: no amount of protest is going to make people stop using the word "transpiler".

It is generally assumed that a compiler goes from high level to low level, a decompiler low-to-high and a transpiler high-to-high. I guess in this case the transpiler is low-to-low, so maybe "transpiler" is just used to mean "samey-to-samey"

> At the point where we are calling things that compile to assembly "transpilers" I don't think there is any distinction left

"Transpiler" is grating (apparently).

does this seems like another instance of the annoying practice in our field of someone giving a name to a thing because they think it's new, though it's not (ie, source-to-source compilers have been around as long as source-to-bytecode compilers)--no need to re-name them

wish they would just stop it and get the hell off my lawn

Thankfully in most jurisdictions it is forbidden by law to do as such.

https://books.google.com/books?id=l5I_AQAAIAAJ&q="transpiler...

What is that distinction? Excluding the javascript crowd, I doubt this phrase will see extensive use in the field until the term gets properly defined and is meaningfully distinct from the word Compile as used today.

[1] - https://news.ycombinator.com/item?id=16076823 [2] - https://hackernoon.com/moving-to-es6-babel-and-transpilers-3...

The frustrating bit is that this is absolutely not true. A compiler is anything that parses some text according to some grammar, manipulates it, and emits it in a different format. While the most well-known and popular compilers are for C, to emit machine code, there's nothing inherent in the definition of a compiler that means it can't emit something human-readable.

I wouldn't have nearly as much issue with this if the JavaScript community instead had decided "compiler isn't specific enough: we need different words for compilers that drop vs. maintain a level of abstraction", rather than "we need a word for a thing like a compiler, but that doesn't, as compilers apparently inherently do, drop a level of abstraction".

Then the JS world came along and decided to use a new word to make it look more hip and cool.

A friendly FYI... the old word "transpiler" has been around since at least the 1960s. See the 2nd-to-last paragraph on the last page:

http://comjnl.oxfordjournals.org/content/7/1/28.full.pdf+htm...

[0]edit: Apparently 60's.

Is it YACT now?

Just ask folks how this term differentiates from Compile and you'll get wildly varying answers and definitions.

Using the term for anything where the source is JVM bytecode is plain wrong, and it's also dubious for anything targeting WebAssembly (though if the target is specifically .wat/.wast, it may perhaps be arguably defensible.)

so i guess one might use "transpile" wrt bytecode in the spirit of that. but i guess asm source files are still "human readable", where bytecode generally isn't considered as such.

[0] P47, "TRANS": http://www.patersontech.com/dos/Docs/86_Dos_usr_03.pdf

[1] http://www.s100computers.com/Software%20Folder/Assembler%20C...

I don't see why the existence of a grey area should be enough to question the utility of the term.

If compile/decompile are used for a transformations along one axis, transpile is used for transformations that are predominantly orthogonal to that axis.

Given the large inconsistency and incompatibility between all these definitions and the existence of a well-accepted term that comprises all of these definitions, is it a mystery why people question the utility of the term? After all, what use is a nuanced term if it can't reliably convey that additional information.

I would recommend the general term "A/B compiler" where A and B are arbitrary regular languages. That way it would be pretty clear what a Pascal/C compiler is, or a JVM/Webasm compiler, for instance. Or a x86/C compiler which would also make the word "decompiler" obsolete.