Comment by wruza
6 years ago
Function environments, resumable coroutines and dsl-friendly syntax is what makes Lua feel so superior to js (in a sense of the language power, not in syntax, optimization or minor design details). It is a shame that browser vendors said “nah, too hard” for coroutines and resorted to generator hack for asynchronous operation – and no one reputable complained! I don’t get it why the execution model should suffer just because someone finds it tedious to split their 300 C calls to few continuation callbacks.
The entire JSX thing could be replaced by something similar, seamlessly connecting code and hyperscript. Callbacks could operate directly on “this”, like in “onclick() {count++}” without making every damn “count” a silly lexically visible [count, setCount] couple. Every missing conceptual feature in js is a total collapse of an entire dimension of possibilities. And yet it is “a language of the future”. How we got here?
The reason explicit asynchrony produces more reliable software than implicit cooperative threading like Lua coroutines is explained at book length in the doctoral dissertation of Mark S. Miller: http://www.erights.org/talks/thesis/markm-thesis.pdf
He is one of the main participants in the ECMAScript committee.
If you disagree with his arguments, please explain why. But you don't seem to have heard of them in the first place, simply assuming that the reason JS isn't designed the way you would have designed it is because the designers weren’t as smart as you are, explaining their choice as “someone finds it tedious to split their 300 C calls to few continuation callbacks.” Sometimes people will disagree with you for reasons other than being stupid or lazy.
Would you be willing to explain why explicit asynchrony is superior to implicit cooperative threading? Rather than simply engaging in more namecalling.
Mutable state is always a problem, but it's a bigger problem when there are less constraints on when it can mutate. But Mark's dissertation explains this and some related issues a lot better.
Also, I don't think I did any name-calling?
4 replies →
I’m not going to read this 229-page doctoral dissertation book for two reasons.
First, it is too long to be practical. Please don’t push the doctoral things on me, we all know that 99.(9)% of what we do in js is not a rocket science. If you want me to feel stupid before someone more educated, fine, I’m okay with that. But even if that’s true, people love to experiment and find their best ways to do something. Also it’s not me who implemented coroutines in Lua this way, it’s PUC Rio guys who made it looking at Scheme. I trust them better than a committee that required 30(?) years to make something bearable without transpilation from the future and hundreds of polyfills.
Second, I’ve asked this question before, and it was browser guys who said that they are not willing to do that, because the legacy is real. And webassembly will not support that neither, because it works in a browser and should obey its rules. Whatever that dissertation concluded, it is committee+browser decision to strip all possible source languages from having such coroutines when targeted at webassembly. It is simply not fair, freedom restricting and has nothing to do with someones educated opinion.
JS is designed in part based on lessons learned from the mistakes of past languages.
Scheme doesn't have coroutines as such; it has first-class continuations.
You can definitely implement cooperative threading in a compiler whose target language doesn't have any kind of threads. You know the 386, SPARC, and PDP-11 don't have threading? It's all simulated. (Wasm probably will have first-class shared-memory threads though. It's being trialed in Chrome already.)
2 replies →