Hacker News Reader

Comment by monocasa | Hacker News Reader

<soapbox>I really dislike the term 'transpile'. It's just a compiler. There's nothing really different in theory or implementation of a "source"->"source" vs a "source"->"binary" compiler. If I were to write a CPU in HDL that natively executed JavaScript, would this change from a 'transpiler' to a 'compiler'. The distinction made is simply what the end user is going to do with the result.</soapbox>

View on HN

I like the distinction in the sense that transpilers generally don't do optimization. GWT, Dart2JS, and Closure Compiler aren't transpilers in this sense. They are full blown optimizing compilers.

Putting GWT or Closure in the same category as JSweet, TypeScript, or CoffeeScript obfuscates what these tools do.

So if I run gcc with -O0, it's a transpiler? Remember that gcc outputs a human readable language that another program (the assembler) converts into machine code.

In one sense yes, but GCC the utility is an optimizing compiler.

Would you call a sed script which converted Java to ES6 via regexes a compiler, even though not an ounce of compiler theory was used?

I would define transpilers as a subset of compilers that are are only interested in high level language conversion.

It's the difference between say, translating books between foreign languages, and being an editor who rewrites a book to be better.

I mean... sed is Turing complete. Yeah, it's in the Turing tarpit, but if you were able to successfully translate Java to ES6 in a sed script, yes I would call that a compiler. In a lot of ways, much of compiler theory is concerned with the best way to write a compiler (for many different optimization functions of "best"), not the only ways to do so. Just being a crappy compiler doesn't make it any less of a compiler.

In that same vein, what's the point of the term "interpreter"? Isn't an interpreter just compiling source code into an in-memory representation, and then executing that?

I'd argue that terms like "interpreter", "compiler", "decompiler", "transpiler", etc. are helpful for establishing a general taxonomy of program transformation tools, even if the boundaries aren't so clear.

The distinction between execution and transformation is a useful one. For instance, depending on the semantics of the source language, you could be able to guarantee termination of a specific transformation of that source, but not be able to guarantee termination of execution of that source.

This comes up every time the term is used, but I don't get it. It's hardly the first time we've introduced redundancy in English, and it won't be the last.

As to your question, it doesn't really make sense for something to "change" from a transpiler to a compiler, any more than it makes sense to change from a Ford to a car. All transpilers are compilers; "transpiler" is just a little more specific. You know, like "gigantic" is a little more specific than "big", or "square" is a little more specific than "rectangle".

FWIW, I disagree with cromwellian that it's anything to do with optimization. I wouldn't personally say CPython transpiles Python to bytecode, but I'd also say an optimized transform from Dart to JS is a transpile. In my eyes, a transpiler is just any compiler where the target language is only intended to be written by humans.

(This changes over time, though. I'd probably not call Nim to C a transpile, although I might have in the past. We're probably reaching the point where X to JS stops being a transpile, too.)

> This changes over time, though. I'd probably not call Nim to C a transpile, although I might have in the past.

You think that I can take a program, run it on some input in the past, and it's a transpiler, assuming that it fits the other part of your definition. Then I wait, say 10 years, run that same program on the same input and now it's not a transpiler?

Reply on news.ycombinator.com