Looks like everyone want to add some missing info. The github source code link can be found at the top right corner. For easy reference, here it is
https://github.com/mohd-akram/languages
So, you can apparently compile C++ to LLVM-IR, then to Javascript, then to Python and then to C++ (you can do similar feat with C). Wonder if there is a fix point, or it diverges.
I looked at js2py (the most surprising-to-me link in that chain) the code it generates already kind of explodes on loc. I think it's probably very unlikely there is a fixed point instead of an exponential explosion of your program as you run it through the chain.
By the pigeonhole principle, any such iteration must either enter a cycle, or the translations must be unbounded in length. If you experiment, you will find that Google Translate usually lands in the first category; transpilers usually land in the second.
Almost all compilers producing machine code can instead also produce assembly. In fact, many compilers internally produce assembly and then run an assembler to produce machine code. So the Assembly node is missing many in arrows.
I can finally fulfill my dream of writing cross-platform C++ by transpiling for the JVM. It's just too bad I have to convert from LLVM to JS to Python first. And then I could convert back to C++ and start over again...
Neat visualization! I wonder how large it could get if people could add their own nodes and edges.
Python doesn't compile Python to C, non-technically or otherwise. Where did you get that impression?
I presume they don't include internal IRs like Python bytecode, as it's not any kind of shared or standardised format. Otherwise you'd be including tons of different compiler IRs.
I thought it maps your code to the base Py_Object like how writing an extension works? Idk only done a little bit of that and need to dive into the process more. On my todo list so if you have some links that have a good explanation of this that would be great. Unfortunately was unable to take compilers in school so missed out on the conceptual aspect of the compilation process.
edit: found the docs on python.org for the compiler [1]
I think the correct representation of this is Rust to LLVM IR (which is there), then LLVM to WebAssembly (which should be there but isn't).
Actually, WebAssembly as a compile target is just generally not there on the graph, which is weird. The Wasm compiler scene is pretty rapidly fluctuating though.
I can vouch for this library, I recently had to do some graphing and tried sigmajs first, but I ended up rewriting it to use cytoscape. Cytoscape is incredibly powerfull, although it would help if they had split up the documentation into multiple pages so that Google works on it.
Compilation is the act of generating a back-end code. Most languages compile to Machine Code, but you could also compile to some other language like C, Haskell, Javascript that you know has a very well-optimized compiler. Say, if you generate C code, and do it well, you know that your language will be almost as fast as C.
Java compiles to a bytecode which is not machine code. Once bytecode is executed on target platform runtime, it is then compiled down to machine code.
But there's more to it than that. The bytecode is actually interpreted at first by the JVM runtime. The code is also continuously dynamically profiled. There are two compilers C1 and C2.
Whatever functions are using the most cpu time get compiled using C1. C1 rapidly compiles to poorly optimized code, but this is a big speedup over the bytecode interpreter. The function is also scheduled to be compiled again in the near future using the C2 compiler. The C2 compiler spends a lot of time compiling, optimizing and aggressively inlining.
But there's more. C2 can optimize its compile for the exact target instruction set, plus extensions, for the actual hardware it is running on at the moment. An ahead of time C compiler cannot do that. It needs to generate x86-64 code that runs on a large variety of hardware processors.
But there's more. The C2 compiler can optimize based on the entire global program. Suppose a function call from one author's library to another author's library can be optimized in some way by writing a different version of that function. C2 can take advantage of this and do it where a C compiler can not because it doesn't know anything about the insides of the other library it is calling -- which might be rewritten tomorrow, or might not be written yet. Once the Java program is started, the C2 compiler can see all parts of the running program an optimize as needed.
But there's more. Suppose YOUR function X calls MY function Y. If your function X is using much CPU, it gets compiled to machine code by C1, and then in a short time gets recompiled again by C2. The C2 compiler might inline my Y function into your X function. Now suppose the class containing my Y function gets dynamically reloaded. Your X function now has a stale inlined version of my Y function. So the JVM runtime changes your X function back to being bytecode interpreted once again. If your Y function is using a lot of CPU, then it gets compiled again by C1, and then in a while, by C2.
All this happens in a garbage collected runtime platform.
It is why Java programs seem to start up, but take a few minutes to "warm up" when they start running fast. Many Java workloads are long running servers, so startup is infrequent.
Now you know why Java can run fast for only six times the amount of memory as a C program.
Alternative non-joke: JavaScript is important to the web, just like machine code is important to computers. Actually, many believed JavaScript was the assembly of the web (just attempt to read the minimized scripts running in your browser), until WebAssembly...
I think the quality of JavaScript as a language is completely irrelevant. It is because it's the only* language that runs in web browsers. So if you want your stuff to run there, you have to target JavaScript.
If WATFIV was the only language that ran in browsers, everything would target it, too.
Nah. It's just that different people have different tastes. Don't compare JavaScript alternatives to people wanting an alternative to Java bytecode; compare JavaScript alternatives to people wanting an alternative to Java.
It's just that, at least for the first couple decades of its existence, the platform in question had no bytecode, so transpiling was the only way to escape.
It says V8 compiles JavaScript to Machine Code, but is that really correct given that the machine code is an intermediate product, and the result of applying a JIT to a specialized piece of code (where part of the variables are already known to the compiler)?
I guess what you're saying is that machine code is an "intermediate product" in the sense that the final product must include the compiler, and the machine code produced by a JIT compiler is useless by itself. And I agree with your overall point, JIT compilers and VMs shouldn't be in there. You might as well include all interpreters. If you look at a JIT compiler as a black box, it acts like an interpreter, and I'm pretty sure this is meant as a practical graph ("what can I do with this language") rather than one that describes the internals of compilers and interpreters.
But let's say, they added "decompilers" to the graph, and there is (say) a decompiler from machine code to C. Then I'd assume, because there is a path in the graph from JavaScript to C (going through machine code), that I can translate from JavaScript to C. Except this isn't true because V8 is a JIT, and doesn't output its internal representation.
It's not a graph of compilers to a file on disk. It's a graph of compilers. Just because it exists only in memory doesn't mean it doesn't exist. Has the JavaScript been compiled to machine code. Yes, it has.
You mean that the JavaScript compilation is only valid for a given application at a given point in time? Yes that's true.
What I meant is: the graph is more useful if you can apply the relations transitively (i.e. find one or more paths between any two languages, and use the compilers to walk along the path). The demo even suggests that by allowing you to find a path, and leave the "directly" box unchecked.
I suspect it was developed on a trackpad, which has pixel-level scroll precision. Zooming is a bit fast but generally fine on my MacBook Pro. Probably anything like this should have a zoom slider (like Google Maps does) for people without precise scrolling or pinch zoom.
For Haskell -> JVM, there is Frege/Eta compiler. You could argue those are dialects of Haskell, but are pretty close. The differences will be around FFI because of jvm
One problem with this graph is that not all links actually support the full language. J2objc actually places constraints on your code so in some sense it's really compiling some (large) subsets of Java.
