Hmm, so assembly code doesn't have any type safety or high level features. So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right? What a load of crap and the op is down voted!!!
You are writing java and barring some features like multi-threading, you CAN write anything you want. How to translate that to JS is the compiler's job, you need not care.
>So when I code in a higher level language I shouldn't be able to actually program in it because assembly doesn't support it, all I am doing is writing in a assembly framework and can't really do more than what it permits, right?
Javascript is not the equivalent of assembly. Javascript is, itself, a higher-level language. You're talking about translating from one high-level language to another, and expecting the interpreter for the latter to care anything about the rules of the former.
>What a load of crap and the op is down voted!!!
The entire thread is downvoted. It's annoying but it doesn't prove anything.
> Javascript is not the equivalent of assembly. Javascript is, itself, a higher-level language. You're talking about translating from one high-level language to another, and expecting the interpreter for the latter to care anything about the rules of the former
What of it? You can write Javascript by hand which would be good strongly typed code, even if there is no compiler or runtime checks to enforce this. OCaml has js_of_ocaml, which can turn 99% of valid OCaml code into Javascript. And OCaml's type system is a hell of a lot more strict than Java's. Whether or not there are runtime checks is irrelevant. The fact that it is valid OCaml code gives you compile-time guarantees when it comes to the types involved. It's a bit like the way that type erasure works in Java. It gives you compile-time guarantees, but the runtime has no idea about it.
> You're talking about translating from one high-level language to another, and expecting the interpreter for the latter to care anything about the rules of the former.
Actually, no, you aren't. The compiler cares about the rules of the language being compiled. The interpreter of the target language doesn't have to care, because code that violates the rules isn't output by the compiler. There's nothing special about high-level languages as a target, its exactly the same situation as any compiler for any general purpose machine (the only thing that might be different is a compiler for a language-specialized VM, but even for those generally many rules of the language aren't present in the VM and exist only in the compiler.)
> You're talking about translating from one high-level language to another, and expecting the interpreter for the latter to care anything about the rules of the former.
Yes; but the Closure compiler knows about the semantics of JS and generates a shitload of disgusting low-level wrappers and checks that implement the retarded JS semantics. You're right in that there are cases where this breaks down, but Closure is not really a high-level-language to high-level-language compiler. The JS output is not in any way human readable (look, for example, at http://de.indeed.com/s/8a9f5dc/jobsearch-all-compiled_de.js).
You are writing java and barring some features like multi-threading, you CAN write anything you want. How to translate that to JS is the compiler's job, you need not care.
Edit: what would you say to this - http://www.scala-js.org ?