Whenever someone argues the uselessness or redundancy of a particular word, a helpful framework to understand their perspective is "Lumpers vs Splitters" : https://en.wikipedia.org/wiki/Lumpers_and_splitters
An extreme caricature example of a "lumper" would just use the word "computer" to label all Turing Complete devices with logic gates. In that mindset, having a bunch of different words like "mainframe", "pc", "smartphone", "game console", "FPGA", etc are all redundant because they're all "computers" which makes the various other words pointless.
On the other hand, the Splitters focus on the differences and I previously commented why "transpiler" keeps being used even though it's "redundant" for the Lumpers : https://news.ycombinator.com/item?id=28602355
We're all Lumpers vs Splitters to different degrees for different topics. A casual music listener who thinks of orchestral music as background sounds for the elevator would be "lump" both Mozart and Bach together as "classical music". But an enthusiast would get irritated and argue "Bach is not classical music, it's Baroque music. Mozart is classical music."
The latest example of this I saw was someone complaining about the word "embedding" used in LLMs. They were asking ... if an embedding is a vector, why didn't they just re-use the word "vector"?!? Why is there an extra different word?!? Lumpers-vs-splitters.
"Compiler" encompassing "transpiler" I think is wrong anyway. There's a third term that doesn't seem to get nearly as much pushback, that didn't come up in your link, has yet to be mentioned here, and isn't in the article, but adds context for these two: decompiler.
Compiling is high-level to low-level (source code to runnable, you rarely look at the output).
Decompiling is low-level to high-level (runnable to source code, you do it to get and use the output).
Transpiling is between two languages of roughly the same level (source code to source code, you do it to get and use the output).
Certainly there's some wishy-washy-ness due to how languages relate to each other, but none of these terms really acts like a superset of the others.
I think the argument here is not really where one should draw the line and whether transpiler should be a different word...
I think the argument centers on how transpilers are often justified as being something quite different in difficulty than writing a whole compiler -- and in practice, nearly the whole set of problems of writing a compiler show up.
So, it's more like, don't use the distinction to lie to yourself.
It's all about context, isn't it? "Humans vs. animals" is an important distinction to make in some contexts and useless in others. Insisting on the fact that humans are also animals if we're talking about, say, "language in humans vs. animals" is unproductive. It just makes discussions harder by forcing everyone to add "_non-human_ animals" to every mention. But if we're talking about, say, cellular biology, it's unproductive to force everyone to write "human and animal cells" instead of just "animal cells".
Similarly, distinguishing between transpilers and compilers might be important in some contexts and useless in others. Transpilers are source-to-source compilers, a subset of compilers. Whether it matters depends on the context.
>An extreme caricature example of a "lumper" would just use the word "computer" to label all Turing Complete devices with logic gates.
"Computer"? You mean object, right?
I don't understand what the issue is: a transpiler is a compiler that outputs in a language that human programmers use.
It's good to be aware of that from an engineering standpoint, because the host language will have significantly different limitations, interoperability and ecosystem, compared to regular binary or some VM byte-code.
Also, I believe that they are meaningfully different in terms of compiler architecture. Outputting an assembly-like is quite different from generating an AST of a high-level programming language. Yes of course it's fuzzy because some compilers use intermediate representations that in some cases are fairly high-level, but still they are not meant for human use and there are many practical differences.
It's a clearly delineated concept, why not have a word for it.
GCC outputs textual GNU assembly language, in which I have written, for example, a web server, a Tetris game, a Forth interpreter, and an interpreter for an object-oriented language with pattern-matching. Perhaps you are under the illusion that I am not a human programmer because this is some kind of superhuman feat, but to me it seems easier than programming in high-level languages. It just takes longer. I think that's a common experience.
Historically speaking, almost all video games and operating systems were written in assembly languages similar to this until the 80s.
Of course I'm aware of this, I've written some assembly too, most definitions are leaky. And if GNU assembly had wide adoption among programmers right now and an ecosystem around it, then some people might also call GCC a transpiler (in that specific mode, which is not the default), if they care about the fact that it outputs in a language that they may read or write by hand comfortably.
They also called C a high-level language at that time. There was also more emphasis on the distinction between assemblers and compilers. Indeed, they may have used the word compiler more in the sense we use transpiler now, I'm sure people were also saying that it was just a fancy assembler. Terminology shifts.
Thank you for the link; I've responded comprehensively at https://news.ycombinator.com/item?id=45914592.
Youâre being \__
The issue is confused because of Javascript and the trend to consider Javascript "bytecode for the web" because it is primarily "compiled" from other languages, rather than being considered a language in its own right.
I've gotten into arguments with people who refuse to accept that there is any difference worth considering between javascript and bytecode or assembly. From that perspective, the difference between a "transpiler" and a "compiler" is just aesthetics.
I do think you are right, the concept is not common outside of the JS ecosystem to be fair. Indeed, it probably wouldn't make much sense to transpile in the first place, if it wasn't for these browser limitations. People would just make fully new languages, and it is starting to happen with WebAssembly.
And the ecosystem of JVM and BEAM hosted languages does make the concept even murkier.
I think the term transpiler is ok. Itâs not pedagogical or anything but most engineering jargon is like that, and this defiantly isnât the worst one Iâve seen.
In the academic programming languages research community, the term "transpiler" is barely used.
For example, Google Scholar search for "transpiler" yields just 3200 results, compared to ~1.4M for "compiler".
Transpilers are compilers that translate from one programming language to the other. I am not 100% sure where these "lies" come from, but it's literally in the name, it's clearly a portmanteau of translating compiler... Where exactly are people thinking the "-piler" suffix comes from?
Yes, I know. You could argue that a C compiler is a transpiler, because assembly language is generally considered a programming language. If this is you, you have discovered that there are sometimes concepts that are not easy to rigorously define but are easy for people to understand. This is not a rare phenomenon. For me, the difference is that a transpiler is intending to target a programming language that will be later compiled by another compiler, and not just an assembler. But, it is ultimately true that this definition is still likely not 100% rigorous, nor is it likely going to have 100% consensus. Yet, people somehow know a transpiler when they see one. The word will continue to be used because it ultimately serves a useful purpose in communication.
One distinction is that compilers generally translate from a higher-level language to a lower-level language whereas Transpilers target two languages which are very close in the abstraction level. For example a program that translated x86 assembly to RISC-V assembly would be considered a transpiler.
The article we are discussing has "Transpilers Target the Same Level of Abstraction" as "Lie #3", and it clearly explains why that is not true of the programs most commonly described as "transpilers". (Also, I've never heard anyone call a cross-assembler a "transpiler".)
On the contrary: it reifies people's prejudices and prevents them from seeing reality, often in the service of intentional deception, which for my purposes is the opposite of a useful purpose in communication.
There's currently a fad in my country for selling "micellar water" for personal skin cleansing, touted as an innovation. But "micelles" are just the structure that any surfactant forms in water, such as soap, dish detergent, or shampoo, once a certain critical concentration is reached, so "micellar water" is just water with detergent in it. People believe they are buying a new product because it's named with words that they don't know, but they are being intentionally deceived.
Similarly, health food stores are selling "collagen supplements" for US$300 per kilogram to prevent your skin from aging. These generally consist of collagen hydrolysate. The more common name for collagen hydrolysate is "gelatin". Food-grade gelatin sells for US$15 per kilogram. (There is some evidence that it works, but it's far from overwhelming, but what I'm focusing on here is the terminology.) People believe they are buying a special new health supplement because they don't know what gelatin is, but they are being intentionally deceived.
You might argue, "People somehow know micellar water when they see it," or, "People somehow know collagen supplements when they see them," but in fact they don't; they are merely repeating what it says on the jar because they don't know any better. They are imagining a distinction that doesn't exist in the real world, and that delusion makes them vulnerable to deception.
Precisely the same is true of "transpilers". The term is commonly used to mislead people into believing that a certain piece of software is not a compiler, so that knowledge about compilers does not apply to it.
> The term is commonly used to mislead people into believing that a certain piece of software is not a compiler, so that knowledge about compilers does not apply to it.
Why would people use a word that has the word "compiler" in it to try to trick people into thinking something is not a compiler? I'm filing this into "issues not caused by the thing that is being complained about".
I like the cover of the book Crafting Interpreters: https://craftinginterpreters.com/image/header.png
It's basically a flowchart showing all of the different things that we mean when we say compiler/interpreter/transpiler, and which bits they have in common.
Funny, but it has two paths for transpiler - the kind that parses and outputs source from an AST, and the asm.js kind, that actually just uses a high-level language as an assembly-ish target.
A compiler takes in one language and outputs some other language. E.g. C to LLVM IR or LLVM IR to x86_64 assembly.
An assembler is a type of compiler that takes in an assembly language and outputs machine code.
A transpiler is a type of compiler that takes in a language commonly used by humans to directly write programs and outputs another language commonly used by humans to directly write programs. E.g. c2rust is a C to unsafe Rust compiler, and since both are human-used languages it's a transpiler. Assembly language isn't commonly written by humans though it used to be, so arguably compilers to assembly language are no longer transpilers even though they used to be.
The existence of a transpiler implies a cispiler, a compiler that takes in code in one language and outputs code in that same language. Autoformatters are cispilers.
Partial evaluators would also be considered cispilers.
> We can make it a bit more terse using list comprehensions:
import functools as ft
def fact(n):
lst = range(1, n)
return ft.reduce(lambda acc, x: acc*x, lst)
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.