My point was that usually a language does more to sell itself. The selling point of C++ wasn't "here's a language that compiles to C" (which it was in the beginning), but rather "Here's a safer, OO version of C with many new features."
Yeah, which is why traditionally a LOT of languages, particularly early in their careers, have compiled down to C. Really aside from JVM targeted languages, it still tends to be the trend.
So it is pretty weird for that to be highlighted as the big distinctive feature.
> Yeah, which is why traditionally a LOT of languages, particularly early in their careers, have compiled down to C. Really aside from JVM targeted languages, it still tends to be the trend.
What about .net/mono targeted languages, javasvcript targeted languages? And custom interpreters jit(frequently but not always written in c)
LLVM has C backend, though it is not fully supported. It seems like it would.be helpful for bootstrapping LLVM for a new architecture and for A/B testing of other backends' performance and correctness.
Sure, but that doesn't make it a good intermediate representation for a programming language. I really like CoffeeScript, but compiling to it would be insanity.
That said, there are some good reasons for compiling to C. Not every architecture has a backend for LLVM yet, after all.
Some would say "I really like JavaScript, but compiling to it would be insanity." And yet CoffeeScript is there. How is that better than a language which compiles to C?
"it automatically implies a pretty high baseline of performance"
I doubt that. It may be (mostly) true for languages that match the capabilities of C well, but if a language does not match C well, it certainly isn't 'automatically' because the optimizer in your C compiler will not help much in making the implementations of such features efficient.
For example, compiling JavaScript to C, it would be non-trivial to make the result as fast as the current JavaScript engines because the C code would likely have to do the same zillions 'is this a string?' checks that interpreters do (probably even more of them because it is harder to see the wood for the trees in your translated-to-C code)
For example, it would require lots of work to support, for example, Lisp's number system, Dylan's union types, any variant of 'eval', or, to take an extreme example, to map Intercal code sequences to efficient C operations such as '+'.
Not really. There is a C compiler for every platform worth its salt.
My point was that usually a language does more to sell itself. The selling point of C++ wasn't "here's a language that compiles to C" (which it was in the beginning), but rather "Here's a safer, OO version of C with many new features."
Some of us rather like C...
Yeah, which is why traditionally a LOT of languages, particularly early in their careers, have compiled down to C. Really aside from JVM targeted languages, it still tends to be the trend.
So it is pretty weird for that to be highlighted as the big distinctive feature.
> Yeah, which is why traditionally a LOT of languages, particularly early in their careers, have compiled down to C. Really aside from JVM targeted languages, it still tends to be the trend.
What about .net/mono targeted languages, javasvcript targeted languages? And custom interpreters jit(frequently but not always written in c)
1 reply →
LLVM has C backend, though it is not fully supported. It seems like it would.be helpful for bootstrapping LLVM for a new architecture and for A/B testing of other backends' performance and correctness.
Sure, but that doesn't make it a good intermediate representation for a programming language. I really like CoffeeScript, but compiling to it would be insanity.
That said, there are some good reasons for compiling to C. Not every architecture has a backend for LLVM yet, after all.
Some would say "I really like JavaScript, but compiling to it would be insanity." And yet CoffeeScript is there. How is that better than a language which compiles to C?
2 replies →
C is eternal. Have you tried Go?
I have not... Should I?
1 reply →
Well, it automatically implies a pretty high baseline of performance and (if it's done right) unmatched portability.
"it automatically implies a pretty high baseline of performance"
I doubt that. It may be (mostly) true for languages that match the capabilities of C well, but if a language does not match C well, it certainly isn't 'automatically' because the optimizer in your C compiler will not help much in making the implementations of such features efficient.
For example, compiling JavaScript to C, it would be non-trivial to make the result as fast as the current JavaScript engines because the C code would likely have to do the same zillions 'is this a string?' checks that interpreters do (probably even more of them because it is harder to see the wood for the trees in your translated-to-C code)
For example, it would require lots of work to support, for example, Lisp's number system, Dylan's union types, any variant of 'eval', or, to take an extreme example, to map Intercal code sequences to efficient C operations such as '+'.