Right off the bat, that sounds like a word with a commonly understood meaning.
There are two classes of languages
* Interpreted, easy to learn, emphasize fast edit-debug cycles
* Compiled, harder to learn, more performant
Prototyping in python and rewriting in C++ or Rust is known as the "two language problem". Many of these efforts are trying to make the two language problem go away. Python -> Rust being the most in demand.
Note that both languages may be statically typed, functional etc.
The term transpiler is useful if we can use it to define meaningful groups of tools that share some attribute that we want to discuss and explore. For example, transpilers typically target much higher level languages than a lot of other compilers, this brings its own challenges that are worth discussing. Or many transpilers need to produce reasonably human-readable output, which is seldom a concern for a lot of traditional compilers.
These aspects are fairly nebulous and it's rarely useful to litigate the details (for example: Js_of_ocaml and Reason both turn OCaml code into JS, but only one of them has readability as an explicit design goal - does this mean only one of them is a "true" transpiler?) but it's still useful to recognise that there exists a subset of compilers that exhibit reasonably unique behaviours that present their own challenges.
"Something that converts source code in a language humans commonly write code in, into another language that humans also commonly (if perhaps less frequently) write code in?"
As opposed to compilation, which is, conversion to something that humans rarely, if ever, write raw?
Anything wrong with this definition?
val greet = (whom: String) => print(s"Hello, $whom!")
to lua local greet = function(whom) print("Hello, " .. whom .. "!") end
I think this is a perfectly reasonable thing to do and it is very straightforward to implement for cases like this in which one truly is just doing syntactic rewrites with no analysis. If I had such a transpiler, I could write new code using my preferred syntax but transpiling to the host language. My project collaborators don't even have to know that this is my process. Writing a transpiler is also a great way to learn a new language since you are forced to learn the language constructs from the bottom up.I do agree with the author though that usually you want to do more than just direct syntactic rewrites. But if you first write a transpiler, then you can extend it to do additional analysis but reuse the code generation components.
An approach I've advocated as one of the main authors of py2many is that all of the python builtin functions be written in a subset of python[1] and then compiled into native code. This has the benefit of avoiding GIL, problems with C-API among other things.
Do checkout the examples here[2] which work out of the box for many of the 8-9 supported backends.
[1] https://github.com/py2many/py2many/blob/main/doc/langspec.md
[2] https://github.com/py2many/py2many/tree/main/tests/cases
It would also scaffold out the project structure for each language.
The idea would be not to allow all code, but focus on high-level intent as simply as possible using primarily builtin language and platform primitives.
Could even use the name of a function and some comments to express the intent, which then gets transpiled in the other language, without even looking at the implementation in TypeScript. Could probably lean on AI a lot.
I’d love to have “one obvious way” to do certain things in each language. This Pythonic rule is violated so often in every language. A lot of programming is the same thing but we all do it slightly differently. Just take a look at some stack overflow answers for really simple stuff.