I feel like the recent podcast could have nailed down these definitions better.
I would put it as roughly
Compiler: one format to another format
Interpreter: executes a format
Transpiler: category of compiler. human readable format to another human readable format
I get that there are still edge cases, but from an understandability perspective, I think these are pretty clear.
JVC: compiler
JVM: interpreter
Elm: transpiler
Roc: compiler
Python: interpreter
CPU: interpreter
I like that! :smiley:
Those seem like good definitions to me, I guess JIT compilers are both interpreters and compilers using these definitions?
I recently heard a nice definition (indented deliberately somewhat colloquially) of a transpiler on the Developer Voices podcast, by the host himself: "A transpiler is a compiler which compiles down to a language you might want to write in" (paraphrased).
Jit compilers are often compilers and interpreters. They first start on interpreter mode. If the code is run enough, it is compiled to assembly.
That said, it depends on the specific jit compiler design and impl. For example, you could jit compile a language by:
This would only be a compiler with the CPU doing all interpreting.
Also, that is a solid transpiler definition as well
Kris Jenkins recently half-jokingly referred to his definition of a transpiler: a compiler that outputs a language you would want to write. :smile:
But Brendan's definition is great — I like making transpilers a subset of compilers, rather than a pejorative “not a real compiler”.
Oops. @Hristo beat me to the Developer Voices anecdote :smile:
Random thought; seems like Roc could be a nice language to create a transpiler with.
No worries, @Zellyn Hunter you probably did the quote better justice than my attempt at paraphrasing from memory :)
:100: regarding Brendan's definitions and expansions upon the concepts!
Last updated: Jul 06 2025 at 12:14 UTC