3 ms·

I have written transpilers and would not want to use the term compiler because it would be a deceptive description of the work involved. It would be a pretentio

I have written transpilers and would not want to use the term compiler because it would be a deceptive description of the work involved. It would be a pretentious aggrandisement akin to saying I built a car because I changed its air freshener. A production ready optimising compiler is one of the greatest achievements in software engineering. A level of complexity and sophistication few of us can reach. A transpiler is often just a trivial text transformation that a junior programmer can do. The purpose may seem superficially similar but the effort and expertise is so totally incomparable that a specific term is justified. edit: it reminds me of the difference between a ship and boat. A transpiler will use some-else's compiler/interpreter but a compiler won't use someone else's transpiler. The two terms are meaningful to those intimate enough to need to distinguish degrees of sophistication but seem redundant to those who merely use them.

Stratoscope 9y ago
Sure, if you're doing a simple text transformation akin to the C preprocessor, then maybe that shouldn't be called a compiler. But we already have a word for that: "preprocessor". Which is probably why, as I mentioned in my other comment, Bjarne was miffed when I called Cfront a preprocessor - it was certainly nothing like the C preprocessor! I guess in today's terminology I would have called it a "transpiler", because it simply transformed one source language to a fairly similar source language and didn't have to optimize the final machine code. But there's a lot more to a compiler than optimization. Take TypeScript for example. Even though it generates JavaScript - and JavaScript that looks very much like the original TypeScript code if you're not having it translate newer syntax to older syntax - it does quite a bit of rather sophisticated work with all the type inference and type checking. TypeScript doesn't need to worry too much about optimization, because it knows that the JavaScript engine that eventually runs the compiled code will do a bunch of JIT optimization. Similarly, a compiler that targets LLVM or the JVM can rely on those engines to do much of the optimization. But the compiler is still a nontrivial piece of work. Maybe I would suggest the term "preprocessor" for something that really is a just a simple text transformation, one that you might implement with regular expressions or hand off to a junior programmer.
- duncanawoods 9y ago
  I see a preprocesser as something distinct from a transpiler - a way to extend a language rather than transform it into another one. This debate is really just about how terms fit a continuum from extension (supported by language constructs) -> preprocesser (add features that can't be supported by host language extensions) -> transpiler (support a totally different but conceptually similar language) -> compiler (conceptual differences from target requiring a more self-standing implementation that tackles fundamental problems). The separation between the levels of sophistication are fuzzy and matters of degree. A single project might legitimately mature through the stages. For example, I don't object to calling Typescript a compiler once it began to generate code for sophisticated concepts not supported by the underlying language.
DonbunEf7 9y ago
Sure, but there's a simpler and already-well-accepted convention for doing this. Say "interpreter" if it takes a program and causes its effects to happen, or "compiler" if it takes a program and emits an equivalent program. If somebody says "transpiler", just mentally replace it with "compiler". Done! Composition of compilers still works as normal. You can use tombstone diagrams to reason about complex chains of compilers and interpreters. And it demystifies the act of building compilers, which is important because otherwise you'll be shaming junior engineers for attempting what is not just the pinnacle of computer science but also our bread and butter. Seriously! Of all the definitions of "transpiler" that I've heard of so far, "compiler but shitty" is the worst yet.
mannykannot 9y ago
I think you are making a very valid point, but is there any practical problem with simply calling them translators?

Stratoscope 9y ago

Sure, if you're doing a simple text transformation akin to the C preprocessor, then maybe that shouldn't be called a compiler. But we already have a word for that: "preprocessor". Which is probably why, as I mentioned in my other comment, Bjarne was miffed when I called Cfront a preprocessor - it was certainly nothing like the C preprocessor! I guess in today's terminology I would have called it a "transpiler", because it simply transformed one source language to a fairly similar source language and didn't have to optimize the final machine code. But there's a lot more to a compiler than optimization. Take TypeScript for example. Even though it generates JavaScript - and JavaScript that looks very much like the original TypeScript code if you're not having it translate newer syntax to older syntax - it does quite a bit of rather sophisticated work with all the type inference and type checking. TypeScript doesn't need to worry too much about optimization, because it knows that the JavaScript engine that eventually runs the compiled code will do a bunch of JIT optimization. Similarly, a compiler that targets LLVM or the JVM can rely on those engines to do much of the optimization. But the compiler is still a nontrivial piece of work. Maybe I would suggest the term "preprocessor" for something that really is a just a simple text transformation, one that you might implement with regular expressions or hand off to a junior programmer.

duncanawoods 9y ago
I see a preprocesser as something distinct from a transpiler - a way to extend a language rather than transform it into another one. This debate is really just about how terms fit a continuum from extension (supported by language constructs) -> preprocesser (add features that can't be supported by host language extensions) -> transpiler (support a totally different but conceptually similar language) -> compiler (conceptual differences from target requiring a more self-standing implementation that tackles fundamental problems). The separation between the levels of sophistication are fuzzy and matters of degree. A single project might legitimately mature through the stages. For example, I don't object to calling Typescript a compiler once it began to generate code for sophisticated concepts not supported by the underlying language.

DonbunEf7 9y ago

Sure, but there's a simpler and already-well-accepted convention for doing this. Say "interpreter" if it takes a program and causes its effects to happen, or "compiler" if it takes a program and emits an equivalent program. If somebody says "transpiler", just mentally replace it with "compiler". Done! Composition of compilers still works as normal. You can use tombstone diagrams to reason about complex chains of compilers and interpreters. And it demystifies the act of building compilers, which is important because otherwise you'll be shaming junior engineers for attempting what is not just the pinnacle of computer science but also our bread and butter. Seriously! Of all the definitions of "transpiler" that I've heard of so far, "compiler but shitty" is the worst yet.

mannykannot 9y ago

I think you are making a very valid point, but is there any practical problem with simply calling them translators?