4 ms·

Because these constant "improvements" usually mean two things: 1. The language design is flawed. That is, the desired functionality requires changes to the co

Because these constant "improvements" usually mean two things: 1. The language design is flawed. That is, the desired functionality requires changes to the core language, because it can't be made from existing building blocks. The fundamental language constructs are not universal enough, so new functionality will always require "just one more" special case in the language itself. or 2. People are shoving things into the core language, that should rather be implemented as a library/framework.

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.
tomxor 9y ago
#1 'use strict' already went a long way to disabling broken parts of the language without breaking backwards compatibility. While what you are saying can be true in general, I find many of the features are more of a design correction that happen to work along side the old flawed way. Take 'var' vs 'let' / 'const' as an example.
- marcosdumay 9y ago
  What will they use once people are mostly using strict, but the language isn't yet good enough (because the keyword is already there, but it still isn't a good language)? Keep adding rules and break the compatibility of strict code, or forget about it and live with current problems forever?
  - tzahola 9y ago
    “use very strict”
    - TomMarius 9y ago
      "use even stricter than very strict";
danbolt 9y ago
20 years ago I used JavaScript to make cute Neopets pages, but today I get asked about how to use it for scalable web services in job interviews. That’s kind of crazy to me! It’d be like if Google made a JIT for LOGO and we all went nuts blogging about using it for ORMs. I think JavaScript’s core foundation is changing because its use cases have rapidly changed. Like C++ or PHP though, it likely has a lot of legacy cruft. Are any Ruby experts able to chime in if its language/runtime changed much after Rails hit the scene?

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.

tomxor 9y ago

#1 'use strict' already went a long way to disabling broken parts of the language without breaking backwards compatibility. While what you are saying can be true in general, I find many of the features are more of a design correction that happen to work along side the old flawed way. Take 'var' vs 'let' / 'const' as an example.

marcosdumay 9y ago
What will they use once people are mostly using strict, but the language isn't yet good enough (because the keyword is already there, but it still isn't a good language)? Keep adding rules and break the compatibility of strict code, or forget about it and live with current problems forever?
- tzahola 9y ago
  “use very strict”
  - TomMarius 9y ago
    "use even stricter than very strict";

danbolt 9y ago

20 years ago I used JavaScript to make cute Neopets pages, but today I get asked about how to use it for scalable web services in job interviews. That’s kind of crazy to me! It’d be like if Google made a JIT for LOGO and we all went nuts blogging about using it for ORMs. I think JavaScript’s core foundation is changing because its use cases have rapidly changed. Like C++ or PHP though, it likely has a lot of legacy cruft. Are any Ruby experts able to chime in if its language/runtime changed much after Rails hit the scene?