4 ms·
> 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
by 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 agoYeah, 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.