3 ms·

For the record, I did not downvote you (I actually upvoted you, since I think your comment contributes to the discussion, even though I disagree with it). > JS

For the record, I did not downvote you (I actually upvoted you, since I think your comment contributes to the discussion, even though I disagree with it). > JS is a great compiler target. The only thing that makes Javascript an attractive compilation target is its ubiquity. The importance of ubiquity should not be discounted. Many languages have succeeded in their target markets on this basis alone, and Javascript may certainly be one of them! But let's not forget that, in almost every other way, it falls short of ideal. Some examples: * Very difficult to parse (while not strictly necessary for a compilation target, still very helpful) * Esoteric type conversion system (leads to bugs) * Lack of integral type (this can be worked around, but the fact that it needs to be worked around makes it a bad target). * Highly dynamic type system (makes it difficult to optimize code, and a good compilation target should be easy to optimize) * Paucity of parsers (I may be wrong, but to my knowledge, there are very few parsers that are neither (A) written in Javascript, or (B) developed as part of a browser rendering engine[0]. If I remember correctly, Facebook's Flow is one of the rare counterexamples[1].) * Single-threaded runtime (makes it challenging to implement languages that explicitly allow parallel execution as part of their semantics) There are ways to address each of these. For example, asm.js limits the scope of the language with the goal of increasing performance of a subset of the language. But they're still shortcomings that have to be dealt with in the first place. Not that any compilation target is perfect in all of the above ways, but Javascript's combination of all of these makes it a very frustrating choice. [0] For example, V8 and Spidermonkey were both originally motivated by Firefox and Chrome. The fact that so few people attempt to write their own (except in Javascript), even for fun/experimentation, should give a very rough indication of how challenging it is. [1] Someone may be able to provide clarity on this: I know Flow is written in OCaml, and I know that at least some of the parsing happens in OCaml, but I also know that Spidermonkey is involved somehow. Is it just that the AST produced is identical to the Spidermonkey AST, or does it actually use Spidermonkey itself at some part of the parsing process?

bobajeff 11y ago
I figured that any attempt to make a superior target language/bitcode would run into the same problem that JavaScript has of eventually needing things bolted onto it making very complex and fall short of perfect in order to fill some important use case the creators didn't think of at the time.
skybrian 11y ago
The Closure compiler both parses and prints JavaScript (it can be used as a minimizer) and it's written in Java. Also, if you're writing a compiler that outputs JavaScript you need to print JavaScript, not parse it, and you can use whatever subset you like. There are hundreds of projects to do this. JavaScript is actually an easier compiler target to deal with than x86 since it's not assembly language and you can read the output, and you don't have to deal with things like register allocation. The hard part isn't generating code; it's making it run fast and reducing the output size so it's competitive with hand-written JavaScript, having great interop with JavaScript so you can reuse existing libraries, and making the whole ecosystem easy to use (editors, debuggers, and so on). GWT was a pioneer in this and TypeScript and Dart are solid efforts. I'm also a fan of GopherJS and Elm. I'm not going to try to pick winners but I think one of them will eventually succeed. As a target language, JavaScript would be fine if it had some additional data types like 64 bit ints. ES6 helps by adding a built-in Map type, and providing a common module system which will help interop. Disclosure: formerly on GWT, now on Dart. But I try not to be partisan.
TazeTSchnitzel 11y ago
> * Very difficult to parse Irrelevant for a compiler target. > * Esoteric type conversion system Mostly not an issue, because compilers are not producing code using the type conversions. > * Lack of integral type JavaScript has integer support up to 32-bit, it just doesn't have 64-bit.
pcwalton 11y ago
There's a huge win in compiling to JavaScript, though: there's a standard that more or less fully describes the language, and there are multiple competing implementations. There are weird corner cases in JavaScript, but they're at least documented. That's more than can be said for most other languages.
orbifold 11y ago
They use the Spidermonkey AST, but the parser is written with OCaml https://github.com/facebook/flow/blob/master/src/parser/parser_flow.ml https://github.com/facebook/flow/blob/master/src/parser/pars... and the Lexer is generated with OCamllex, since there is support for compiling OCaml bytecode to Javascript it still runs in the Browser.

bobajeff 11y ago

I figured that any attempt to make a superior target language/bitcode would run into the same problem that JavaScript has of eventually needing things bolted onto it making very complex and fall short of perfect in order to fill some important use case the creators didn't think of at the time.

skybrian 11y ago

The Closure compiler both parses and prints JavaScript (it can be used as a minimizer) and it's written in Java. Also, if you're writing a compiler that outputs JavaScript you need to print JavaScript, not parse it, and you can use whatever subset you like. There are hundreds of projects to do this. JavaScript is actually an easier compiler target to deal with than x86 since it's not assembly language and you can read the output, and you don't have to deal with things like register allocation. The hard part isn't generating code; it's making it run fast and reducing the output size so it's competitive with hand-written JavaScript, having great interop with JavaScript so you can reuse existing libraries, and making the whole ecosystem easy to use (editors, debuggers, and so on). GWT was a pioneer in this and TypeScript and Dart are solid efforts. I'm also a fan of GopherJS and Elm. I'm not going to try to pick winners but I think one of them will eventually succeed. As a target language, JavaScript would be fine if it had some additional data types like 64 bit ints. ES6 helps by adding a built-in Map type, and providing a common module system which will help interop. Disclosure: formerly on GWT, now on Dart. But I try not to be partisan.

TazeTSchnitzel 11y ago

> * Very difficult to parse Irrelevant for a compiler target. > * Esoteric type conversion system Mostly not an issue, because compilers are not producing code using the type conversions. > * Lack of integral type JavaScript has integer support up to 32-bit, it just doesn't have 64-bit.

pcwalton 11y ago

There's a huge win in compiling to JavaScript, though: there's a standard that more or less fully describes the language, and there are multiple competing implementations. There are weird corner cases in JavaScript, but they're at least documented. That's more than can be said for most other languages.

orbifold 11y ago

They use the Spidermonkey AST, but the parser is written with OCaml https://github.com/facebook/flow/blob/master/src/parser/parser_flow.ml https://github.com/facebook/flow/blob/master/src/parser/pars... and the Lexer is generated with OCamllex, since there is support for compiling OCaml bytecode to Javascript it still runs in the Browser.