The word "transpiler" propagates the misunderstanding that there is something special about a compiler that emits machine code, that requires some special "compiler" techniques for special "compiler" purposes that are not necessary for "transpiler" purposes because "transpiling" requires a completely different set of techniques.
There aren't any such techniques. If one were to create an academic discipline to study "transpilers" and one to study "compilers", all you'd end up with is an identical bunch of techniques and analyses with different names on them. (A thing that sometimes happens when diverse disciplines study what turns out to be the same thing; see machine learning versus statistics for a well-known example.)
Even "compiling" to machine code isn't special anymore, because CPUs don't actually execute assembly anymore. They themselves compile assembly into internal micro-ops, which is what they actually execute. So compilers don't even compile "machine language" anymore; it's just another target. This also dodges "is it a 'compiler' or a 'transpiler' if it targets WASM?", which is good, because there is no value in that question on any level.
1. Transpilers output to another programming language that is typically written by hand by others (so not assembly).
2. Transpilers don’t typically optimize code, leaving those transformations to the compiler of the target language.
3. Compilers will typically have an internal representation (SSA) which they operate on to optimize. Transpilers typically operate on the AST (because they don’t need to do any but the most trivial optimizations).
There are exceptions to the rules but these cover the majority of the reasons on why people make the distinction.
These differences aren't inherent to transpilers vs compilers, they're mostly the result of the fact that the vast majority of transpilers are less mature than the battle-tested compilers that you're thinking of.
The average hobby compiler—regardless of target—doesn't optimize code and works directly on the AST because that's simple to get started with. Most hobby compilers also target some other language rather than LLVM or machine code because that's simple to get started with, so the result is that most transpilers are hobby projects that don't optimize. But there's no reason why a transpiler shouldn't include optimization steps that adapt the output to use code paths that are known to be fast, and a production-grade transpiler typically will include these steps.
> the majority of the reasons on why people make the distinction.
You have provided some defining properties that might allow for distinction, but you have not given any reasons for why people make a distinction.
But perhaps we can suss it out. Given the statement "Borgo compiles to Go", what important information is lost that would be saved if "Borgo transpiles to Go" was used instead?
In that statement, it doesn't really add anything.
In the statement "XYZ is a compiler/transpiler", it does. It doesn't hurt to have a word that is more specific than others. Otherwise we should just refer to compilers as an "app" :)
I don't think anyone here is saying we shouldn't have the word "transpiler" at all, just that "transpiler" is a subcategory of "compiler" and there's no reason for OP to try to correct the title of this story.
It reminds me of how my 5-year-old son always corrects me when I tell him to get in the car—"you mean the van!". I have tried to explain to him that a minivan is a kind of car, and he's just about getting it, but it's been a challenge for him to grasp.
Eh, that's one possible reading, but their actual take is more nuanced than that:
> The word "transpiler" propagates the misunderstanding that there is something special about a compiler that emits machine code, that requires some special "compiler" techniques for special "compiler" purposes that are not necessary for "transpiler" purposes because "transpiling" requires a completely different set of techniques.
In context of the parent comment I read this to be a reaction to someone insisting that we use "transpiler" instead of "compiler"—more an observation of what is happening here than a call to stop using the word altogether.
Someone argues that transpiler adds nothing (no nuance) over the original word. And your takeaway is that “I don't think anyone here is saying we shouldn't have the word "transpiler" at all” and that their original post is “more [of] an observation”? Does a person have to be all boorish and say that “you shouldn’t use that word” in order to convince you that they think it’s useless? Anyway this comment (newer than your comment) seems clear enough: https://news.ycombinator.com/item?id=40214781
> Ultimately, "compiler" isn't a bright shining line either... I can take anything and shade it down to the point where you might not be sure ("is that a 'compiler' or an 'interpreter'?"), but the "transpiler" term is trying to draw a line where there isn't even a seam in the landscape.
As no internet discussion is complete without a car analogy, car and automobile mean the same thing, but I see no reason why one of those terms needs to go away. Why can't transpiler and compiler peacefully coexist with the same meaning?
It doesn't matter but I fully disagree with this. A transpiler emits code the user is supposed to understand, a compiler does not. At least that's the general way I've seen the term used, and it seems quite consistent.
There is a phenomenon I have observed many times where you can get a bunch of people in a room and make some statement, in this case, "Compilers are different than transpilers", and everyone around the table will nod sagely. Yup. We all agree with this statement.
But if you dig in, it will turn out that every single one of them has a different interpretation, quite often fatally so to whatever the task at hand is.
I mention this because my impression has been that the distinction between "transpiler" and "compiler" is that the latter is into some machine code and the former is not. I think if we could get people to sit down and very clearly define the difference we'd discover it is not as universal a definition as we think.
My personal favorite is when I say a particular term is not well defined on the internet, and I get multiple commenters to jump up and tell me off about how wrong I am and how well-defined the term is and how universal the understanding is, while each of them gives a completely different definition. As I write this it hasn't happened in this thread yet, but stay tuned.
Anyhow, the simple solution is, there isn't a useful distinction between them. There's no sharp line anyhow. Plenty of "transpilers" produce things like Python that looks like
and it's really quite silly to look at what can be a very large process and make a distinction only in how the very last phase is run, and on a relatively superficial bit of that last phase too.
2 hours later, I think it's safe to say there are multiple definitions in play that are, if not outright contradictory, certainly not identical.
It seems the term is not terribly useful even on its own terms... it is not as well defined as everyone thinks.
Ultimately, "compiler" isn't a bright shining line either... I can take anything and shade it down to the point where you might not be sure ("is that a 'compiler' or an 'interpreter'?"), but the "transpiler" term is trying to draw a line where there isn't even a seam in the landscape.
> the "transpiler" term is trying to draw a line where there isn't even a seam in the landscape.
I don't think you have proven that it is a seamless landscape. In fact, I think that people's definitions have been remarkably consistent in spite of their fuzziness. The heart of what I have read is that most people understand a transpiler to be an intermediate text to text translation whose output is input to another tool. The common colloquial definition of a compiler is a text to machine code (for some definition of machine code) translation whose output is an executable program on a host platform. You can make an argument that every compiler is a transpiler or every transpiler is a compiler, but I think it requires a level of willful obtuseness or excessive pedantry to deny that there is something behind the concept of a transpiler. This discussion wouldn't even be happening if transpiler were a completely meaningless term.
> , but I think it requires a level of willful obtuseness or excessive pedantry to deny that there is something behind the concept of a transpiler.
Transpiler means something. Fuzzily. And it defines and denotes nothing of practical utility.
> This discussion wouldn't even be happening if transpiler were a completely meaningless term
This discussion wouldn’t even be happening if (people like) JS programmers didn’t insist on using terminology that implied some archaic view of technology, like “compilers emit machine code”—the distinction between high- or low-level target languages aren’t interesting anymore, even if it might have been novel to normie programmers in the 90’s or something.
And in the other corner you have Chomsky with universal grammar... and in another you have Platonic Forms...
I love the "draw me a tree" idea of a Platonic form, we all have an idealized model of what that is, that is uniquely our own. With that in mind isnt everything subject to some sort of semantics?
> A transpiler emits code the user is supposed to understand, a compiler does not.
No, a transpiler emits code that another system is meant to understand (often another compiler or interpreter). Whether a human can understand it or not is immaterial to the objective of transpiling.
> Does that imply that a compiler emits code that nothing can understand?
Bizarre take. No, compilers in the classical sense target byte code and machine code which is meant to be interpreted by a byte code interpreter or a hardware machine.
> Or are you saying that 'transpile' is no more than another word for 'compile'?
Yes. Compilers translate from one language to another. Transpilers translate from one language to another. Both have the objective of preserving the behavior of the program across translation. Neither has the objective of making something intended for humans as a general rule.
That transpiled code (if we draw a distinction) targets languages meant for humans to read/write means that many transpiled programs can be read by people, but it's not the objective.
Bizarre in what way? If compilers are somehow different, then they mustn't target systems, as that's what your previous comment says transpilers do. Which leaves even your own classical definition to be contradictory, if they are somehow different. What does that leave?
> Yes.
But it seems you do not consider them different, which was the divergent path in the previous comment. But evaluating both the "if" and the "else" statement is rather illogical. The evaluation of both branches is what is truly bizarre here.
I see what you mean but how is it academically useful to identify transpilers something of their own? It's still compiling (lowering) from one notation to another.
All compiler outputs are understandable. I suppose you mean with the intent of it being a one-time translation? As in, like when the Go project converted the original C codebase into Go source with the intent of having developers work in the Go output afterwards and the C code to be never touched again?
Yea, not sure i disagree with anything being said here. Though to me, transpiler just typically means it goes from one language i could write, to another i could write. I don't necessarily expect to enjoy reading or perhaps even understanding the JavaScript output from any lang that builds to JS, for example.
Fair, by "could write" i meant one intended for humans to write. Ie i would not say LLVM bytecode is intended for humans to write by hand. Can they? Sure.
The difference (to the parent comment) in my eyes is that the target language is the thing intended for humans, not the target output itself. As another commenter points out, transpiled code is often not intended for humans, even if the language is.
Machine code is intended to be written by humans. That was the only way to program computers at one point in time. Given a machine code target, would you say it is product of transpilation or compilation?
I would stand by my original statement, as i don't consider that "intended" or common by modern day standards. Humans hand wrote binary for a while too hah.
If it's not clear, these are just my opinions. Not an attempt at an objective fact or anything.
I'm fairly certain that source-to-source transpilers rarely use anything like BURS or any other sufficiently smart "instruction selection" (or insturction scheduling, for that matter) algorithms because why would they, the compilers for the targeted language already incorporate such algorithms, maybe even of the higher quality than the transpiler's author are capable to write themselves.
All compilers end up with local considerations. Instruction selection or register allocation is not a consideration special to compilers that "transpilers" do not need to have, they are specific considerations for that particular compiler target. A compiler to Go must consider Go's identifier rules, which does not apply to compilers targeting a CPU. A compiler to SQL must consider valid SQL syntax and have their own optimization concerns that don't apply to Go. And so on.
The middles all look very similar, though, which is where the heart of "compiler" comes from; that process of some sort of parsing and then transforming down to some other representation. This has a distinguishing set of characteristics and problems despite what frontends and backends get slapped on them.
Nothing unholy there. It's easier to transpile to a less constrained language. Transpiling to Rust would require using one of the GC crates or refcount everything. Then you'd have to also satisfy the mutability and send/sync constraints. Go needs none of these things, so all the transpiler needs to care about is it's own added constraints.
Yeah, the top of the project says "compiles", then the readme says "transpiles". Perhaps the author was just trying to get all the SEO terms in there.
> And it's written in rust. Kinda unholy.
Agreed, it's like, do you really hate writing Go so much that you'll really write all that Rust to get out of it? Haha. Reminds me of the web frameworks which generated the JS so you didn't have to touch it, like GWT of old.
I'm sure it was a fun exercise to create Borgo, though.
My favorite transpiler is Haxe. It targets so many other languages, the surface area is impressive.
Thanks, I'd always thought targeted transformations -> transpiler, but it makes sense it's really a subset of general compiler functionality, sans binary output.
It appears to be a transpiler (consumes a Borgo and does the work to convert and emit a Go program as text):
https://github.com/borgo-lang/borgo/blob/main/compiler/src/c...