The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.
It is because of the fact that Clojure and ClojureScript are not really exactly the same language, and are implemented in very different ways from each other, that we can take advantage of many platform-specific features that would otherwise be abstracted.
If you can't implement C on a platform, I think you're in some pretty strange territory and you're probably having to invent your own language to match the platform.
In other words what you call C is actually very different from platform to platform, people solving that with a crap load of ifdef statements.
It is possible to implement C faithfully on these platforms, including all of C's weirdness like pointer-arithmetic and unsafe casting. But you'd end up with something that departs far from the platform's runtime model and calling conventions.
Of course it can. The two platforms you listed can both faithfully emulate an entire computer, upon which you can build your C runtime.
http://bellard.org/jslinux/tech.html
Now, if what you really meant was more along the lines of "can I faithfully cross-compile C to Java bytecode", the answer would be "not without a layer of abstraction".
Can you elaborate? Shouldn't VM just standardize EVERYTHING on the language level? Can you give specific examples when language NEED to be aware of the hardware?
You always need to be aware of the hardware/target-platform. Some examples:
1. Bioinformatics 2. Data storage 3. Any soft real-time application 4. Any kind of constraint search with simulated annealing through large spaces 5. Operating systems 6. Compilers 7. Image recognition/analysis 8. Rendering 9. Basically any application where the user expects a responsive result
You ignore performance at your peril. The reason why we have super-fast computers and software with loading screens is because of this thinking.
If you do have a legitimate reason to run on a VM you should be aware of the burden its abstractions places on your ability to reason about the performance and costs your program will incur.
Someone mentioned C, and it's a good example. C is different on every platform. If your C code interacts with the world in any way, you won't write the same code. Libraries will be totally different, not to mention that pointer sizes are different, byte ordering is different, and even your lowly int might betray you. The reason why C is so practical and widely used is exactly because it doesn't try to force a platform abstraction on you.
In the case of a host language, any integration beyond the most simple with the host is going to require implementation specific code.
True, but some people push the limit of what you can do much farther than others. Take a look at what the ceylon team is doing, to see what you can do if you plan for it from the beginning.
On the other hand, Clojure runs on a platform that is supposedly implementable anywhere.
A: No, and don't waste your time on this talk if you already have watched any of Rich Hickey's talks, this is an ego-stroke at best that introduces no new solutions to any problems. It's an hour and a half of 'Hey look what clojure can do', and 'Gee, our documentation isn't great'.
Maybe someday Clojure will have something like the Shen project has with KLambda. A tight, core language implementable in any language, and a language library built on top of that core language, agnostic of the implementation it's derived on.
If Clojure had gone this route, we could basically have Clojure on any platform capable of parsing and modifying S-Expressions.
Maybe someday!