4 ms·

Why do you find it depressing? I'm not saying that there aren't better programming languages than Javascript. I'm just saying that there is a subset of Javascr

Why do you find it depressing? I'm not saying that there aren't better programming languages than Javascript. I'm just saying that there is a subset of Javascript which is really expressive and elegant.

silentbicycle 16y ago
That elegant, expressive subset is basically Lua. It's been able to jettison most cruft over the years. I'm not a web developer, but every time I read/use Javascript, it feels like a broken fork of my favorite language. Javascript could have been that good, too. I like where Eich was going with it, but the browser wars etc. meant that shipping an early version made the most business sense, and design errors (which would have shaken out) got frozen in the spec.
- BrendanEich 16y ago
  See http://wiki.ecmascript.org/doku.php?id=harmony:harmony http://wiki.ecmascript.org/doku.php?id=harmony:harmony and the pages it links in the first paragraph. ES5 strict (on which Harmony is based) removes or fixes some of the cruftiness. It's not the case that the Web dooms us forever to use JS as it was in 1995. That is simply false on a number of JS-specific points, but more generally: the Web's deployed-browsers-with-enough-market-share-to-matter intersection semantics moves over the years. It does not stay still or grow only compatibly. Bad old forms (plugins, especially, but also things like spacer GIFs used in pre-modern table layouts, not to mention old JS versions) die off. So, cheer up! JS can't be Lua, but it doesn't need to be. Its job is to be the best it can be according to its species and genus, its body plan. Which may be related to Lua's, but which was not and will never be the same as Lua's, because JS and Lua live in quite different ecosystems. A concrete example: Lua has coroutines now, but JS is unlikely to get them in the same way, interoperably. Some VMs would have a hard time implementing, especially where the continuation spans a native method activation. This is a case where Lua's single-source implementation shines, but that's just not going to happen on the web, in variously-implemented, open- and closed-source (the latter including clean-room, for fear of patents) browsers. So, we're aiming for Pythonic generators at most. If we go further than generators, I'll be surprised. Pleased too, don't get me wrong. However I doubt it will happen, because some on the committee do not want deeper continuations than generators, since greater than one frame of depth breaks local security-hat-wearing reasoning about what is invariant in JS's run-to-completion, apparently single-threaded execution model.

silentbicycle 16y ago

That elegant, expressive subset is basically Lua. It's been able to jettison most cruft over the years. I'm not a web developer, but every time I read/use Javascript, it feels like a broken fork of my favorite language. Javascript could have been that good, too. I like where Eich was going with it, but the browser wars etc. meant that shipping an early version made the most business sense, and design errors (which would have shaken out) got frozen in the spec.

BrendanEich 16y ago
See http://wiki.ecmascript.org/doku.php?id=harmony:harmony http://wiki.ecmascript.org/doku.php?id=harmony:harmony and the pages it links in the first paragraph. ES5 strict (on which Harmony is based) removes or fixes some of the cruftiness. It's not the case that the Web dooms us forever to use JS as it was in 1995. That is simply false on a number of JS-specific points, but more generally: the Web's deployed-browsers-with-enough-market-share-to-matter intersection semantics moves over the years. It does not stay still or grow only compatibly. Bad old forms (plugins, especially, but also things like spacer GIFs used in pre-modern table layouts, not to mention old JS versions) die off. So, cheer up! JS can't be Lua, but it doesn't need to be. Its job is to be the best it can be according to its species and genus, its body plan. Which may be related to Lua's, but which was not and will never be the same as Lua's, because JS and Lua live in quite different ecosystems. A concrete example: Lua has coroutines now, but JS is unlikely to get them in the same way, interoperably. Some VMs would have a hard time implementing, especially where the continuation spans a native method activation. This is a case where Lua's single-source implementation shines, but that's just not going to happen on the web, in variously-implemented, open- and closed-source (the latter including clean-room, for fear of patents) browsers. So, we're aiming for Pythonic generators at most. If we go further than generators, I'll be surprised. Pleased too, don't get me wrong. However I doubt it will happen, because some on the committee do not want deeper continuations than generators, since greater than one frame of depth breaks local security-hat-wearing reasoning about what is invariant in JS's run-to-completion, apparently single-threaded execution model.