5 ms·

The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?

by castis 9y ago

tzahola 9y ago
>The language design is absolutely flawed, hence the push to make that less so. But a flawed language cannot be made non-flawed while keeping backwards compatibility... E.g. JS has now two different ways to write functions, with slightly different semantics. >What things going into core do you think should be a separate framework? An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.
- alangpierce 9y ago
  > But a flawed language cannot be made non-flawed while keeping backwards compatibility Sure it can. Just introduce new syntax and discourage use of old syntax, ideally with tooling. For example, `var` is disallowed by any popular lint config, and for most practical purposes, it doesn't exist in JS anymore. The execution environment will still handle it, but it's not an available option when writing code in any professional or non-professional project I work on (because it won't pass lint). Plenty of languages do this: Java raw types, Python old-style classes, goto in lots of languages. Python actually did a breaking change to remove old features, and it's a good example of how breaking changes can cause much more trouble than you might expect.
  - jmull 9y ago
    > ...it's not an available option when writing code in any professional or non-professional project I work on... That is surprising to me. I work with code that is more than a couple years old all the time and I would guess most people do to.
    - alangpierce 9y ago
      Yeah, it's a slight exaggeration to say that `var` is effectively not in the language anymore, e.g. I see it plenty when reading open source projects or Babel output. Keep in mind that ESLint can autofix `var` to `let` or `const` (except in some rare cases when it's unsafe), so even if you have a big legacy codebase, it's not hard to migrate completely away from `var` with very little time or risk. But it's true that you need to keep up with tooling for legacy projects, which happens to be the case for the stuff I work on, but may not be universally true.
- rmrfrmrf 9y ago
  > E.g. JS has now two different ways to write functions, with slightly different semantics. Just 2? More like 9: * function expression * function declaration * arrow function (single line, single param) * arrow function (single line, multiparam) * arrow function (multiline, single param) * arrow function (multiline, multiparam) * object shorthand * class declaration * class expression
  - Veen 9y ago
    It's not just syntactic differences either: they behave differently with regard to whether they're hoisted and the value of this.
- minitech 9y ago
  > An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries. async/await could be implemented with just generators, and were so implemented in ES6; async/await was added to the language because it was convenient. A language without full coroutines is fine.

The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?

by castis 9y ago

The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?

tzahola 9y ago

>The language design is absolutely flawed, hence the push to make that less so. But a flawed language cannot be made non-flawed while keeping backwards compatibility... E.g. JS has now two different ways to write functions, with slightly different semantics. >What things going into core do you think should be a separate framework? An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.

alangpierce 9y ago
> But a flawed language cannot be made non-flawed while keeping backwards compatibility Sure it can. Just introduce new syntax and discourage use of old syntax, ideally with tooling. For example, `var` is disallowed by any popular lint config, and for most practical purposes, it doesn't exist in JS anymore. The execution environment will still handle it, but it's not an available option when writing code in any professional or non-professional project I work on (because it won't pass lint). Plenty of languages do this: Java raw types, Python old-style classes, goto in lots of languages. Python actually did a breaking change to remove old features, and it's a good example of how breaking changes can cause much more trouble than you might expect.
- jmull 9y ago
  > ...it's not an available option when writing code in any professional or non-professional project I work on... That is surprising to me. I work with code that is more than a couple years old all the time and I would guess most people do to.
  - alangpierce 9y ago
    Yeah, it's a slight exaggeration to say that `var` is effectively not in the language anymore, e.g. I see it plenty when reading open source projects or Babel output. Keep in mind that ESLint can autofix `var` to `let` or `const` (except in some rare cases when it's unsafe), so even if you have a big legacy codebase, it's not hard to migrate completely away from `var` with very little time or risk. But it's true that you need to keep up with tooling for legacy projects, which happens to be the case for the stuff I work on, but may not be universally true.
rmrfrmrf 9y ago
> E.g. JS has now two different ways to write functions, with slightly different semantics. Just 2? More like 9: * function expression * function declaration * arrow function (single line, single param) * arrow function (single line, multiparam) * arrow function (multiline, single param) * arrow function (multiline, multiparam) * object shorthand * class declaration * class expression
- Veen 9y ago
  It's not just syntactic differences either: they behave differently with regard to whether they're hoisted and the value of this.
minitech 9y ago
> An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries. async/await could be implemented with just generators, and were so implemented in ES6; async/await was added to the language because it was convenient. A language without full coroutines is fine.