Hacker News Reader

Comment by ane | Hacker News Reader

Is the ad hoc distinction between compilation and "transpilation" really worth it? Can't we just call them compilers? I get that the difference between compilation and transpilation is that the target language of the latter is not a lower lever language, which would be in the case of C and Assembler, but that it targets a language that's more or less of a similar level. Is this really worthy of another term? I'm not sure.

View on HN

While as you point out there's not necessarily an academic difference, the notion that your target language will itself require a compiler and/or runtime is useful to know up front. Transpilers also usually attempt close to 1-to-1 translation. Functions become functions, constants become constants, etc.

As someone who has written many compilers before, I'd almost feel it would be a slight disservice to call a transpiler a compiler, mostly because their architecture and goals are often different.

I think the distinction is useful too, as it gives you a better idea of where a language actually sits in a development workflow.

Then why not just use the term "translator"?

Translate usually means something bijective.

I think it's fine to call it a compiler if it compiles a language to another of a lower level of abstraction, which may be true with compiling lisp to javascript, depending on if macros and read macros were implemented. There's just no way a programmer can manipulate the reader in javascript.

Eval? Code as as string, parse, analyze, etc. Then code gen the JS you need into a string. Eval the string.

I don't see the need for a word beyond "translator" for what you describe. It's a well known word and used correctly, I think, if I say "this program translates Lisp into Javascript."

I'm with you. A transpiler is exactly a compiler.

Maybe the transpiler is just a spackled polyfill enabling splats because dunders are unreliable?

Reply on news.ycombinator.com