5 ms·

How could CSS (or any language) have been designed so that these mistakes could have easily been corrected today in any case? If the mentioned mistakes or simi

How could CSS (or any language) have been designed so that these mistakes could have easily been corrected today in any case? If the mentioned mistakes or similar language design mistakes were made. Because mistakes will always be made. (Unison lang comes to mind but it’s refactor failsafe seems narrow. How about: Antifragile language design? Self-correcting language?)

MrMetric 9mo ago
Simple: A version specifier, or feature specifiers. Backward compatibility concerns vanish when I can opt-in to a newer spec. Old code keeps working, and new code doesn't suffer for legacy nonsense. For example, the Circle compiler extends C++ with its `#feature` directive: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives https://github.com/seanbaxter/circle/blob/master/new-circle/... Sadly, the closest I've personally seen to this sort of thing in widespread use is `"use strict";` in JavaScript, which is only a single binary switch. You can't, say, turn on a new keyword, disable a keyword, switch to a different incompatible version of some browser API, etc. I encourage all language designers to include a feature mechanism in a forward-compatible way. Don't overthink the difficulty: It doesn't need to do anything at first, it just needs to not be a parsing error. Treat it like a comment. FYI, this is the same as having a version number or header size in a binary file format's header, which all sane formats have (there are a lot of insane formats out there...).
- childintime 9mo ago
  Backwards compatibility is overrated. It should be future compatibility, so older browsers get to load a shim to implement new features. That way the onus of incompatibility falls on the older browsers, they get slower over time. Newer browsers get leaner. That's what you want.

MrMetric 9mo ago

Simple: A version specifier, or feature specifiers. Backward compatibility concerns vanish when I can opt-in to a newer spec. Old code keeps working, and new code doesn't suffer for legacy nonsense. For example, the Circle compiler extends C++ with its `#feature` directive: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives https://github.com/seanbaxter/circle/blob/master/new-circle/... Sadly, the closest I've personally seen to this sort of thing in widespread use is `"use strict";` in JavaScript, which is only a single binary switch. You can't, say, turn on a new keyword, disable a keyword, switch to a different incompatible version of some browser API, etc. I encourage all language designers to include a feature mechanism in a forward-compatible way. Don't overthink the difficulty: It doesn't need to do anything at first, it just needs to not be a parsing error. Treat it like a comment. FYI, this is the same as having a version number or header size in a binary file format's header, which all sane formats have (there are a lot of insane formats out there...).

childintime 9mo ago
Backwards compatibility is overrated. It should be future compatibility, so older browsers get to load a shim to implement new features. That way the onus of incompatibility falls on the older browsers, they get slower over time. Newer browsers get leaner. That's what you want.