3 ms·

If you have literally no idea what a good or bad answer even looks like, it's not time to standardize it at this sort of formal level yet. Beyond that, some of

If you have literally no idea what a good or bad answer even looks like, it's not time to standardize it at this sort of formal level yet. Beyond that, some of this is just odd. " It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard." Good. We can deal with that in v2.0. Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know, then i go back to the first sentence i wrote :) Beyond that, your optimism in what will happen (shakeout of bad ideas and then harmonious replacement with standards) seems ... mostly misplaced. Assume it takes off - what will instead happen is that you will be stuck supporting tons of non-standard methods developed between now and when anyone standardizes them forever. It will likely hamstring your future development as well. I cite as evidence - literally the history of everything :) There was 100% no reason to standardize this now other than wanting to feel good about themselves. It isn't needed to push forward. It should have waited until someone had any idea what good looks like.

dmitriid 4y ago
> Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know Whatever you design for the web stays on the web for decades. So yes, you have to look into the future and anticipate things. It's not "move fast and break things"
- DannyBee 4y ago
  I'm not at all suggesting move fast and break things. Yes, things stay for decades. So don't standardize something when you have literally no idea what good looks like. There is a limit to anticipation. Trying to guess what the world will look like 10 years from now is dumb. Nobody does it well. So just because v1 will have inertia doesn't mean you will actually predict the future more successfully. Instead, you have to figure out how you deal with that inertia. In practice, the reason things have tremendous intertia is because they are often not built to be migrated from or to in a relatively seamless way. Those standards that allow for easy migration tend to see much faster adoption of new versions. Those that don't, the old standards linger even longer.
topspin 4y ago
> Good. We can deal with that in v2.0. There are many, many examples of v2.0 standards that, although better in every respect, never actually supplant v1. v1 has immense inertia. It's not all as willy nilly as it might seem. W3C standardized the parts they could without painting themselves into a corner and wisely factored out the part they couldn't. There is an official W3C hosted registry of methods, each with a specification. They vary hugely in purpose, quality and applicability, all of which will eventually determine their viability. There are at least 3 based on the Bitcoin ('btcr', 'ion' and 'stack') block chain, for example. Which, if any, of these should W3C prefer? The fact of this Cabirian explosion supports the W3C argument. Not selecting some arbitrary subset of these as SHALLs in the v1 standard affords room to discover the benefits and pitfalls given time and iteration. I can understand the viewpoint of Mozilla, Google, et al. I'm sure they'd love to throw a room full of coders at a simple specification and knock out a planetary scale identity system, collect a few billion names and sell all that info to the highest bidders before the next quarterly report. It seems that W3C has other ideas about how this should work.
- DannyBee 4y ago
  Yes, v1 often has immense inertia. This is true, but it will actually not make you any better at predicting the future, and as i said elsewhere, we are extremely bad at that already. Step into the shoes of a developer 10 years ago, and look the world now. Look ohw much is changed in a way that would affect this stuff. Trying to have successfully anticipated it simply won't work. Instead, you build standards to be easy to transition from/to. That is what enables you to upgrade standards and get reasonable adoption of new versions. While painful, that is the only path that ever works.

dmitriid 4y ago

> Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know Whatever you design for the web stays on the web for decades. So yes, you have to look into the future and anticipate things. It's not "move fast and break things"

DannyBee 4y ago
I'm not at all suggesting move fast and break things. Yes, things stay for decades. So don't standardize something when you have literally no idea what good looks like. There is a limit to anticipation. Trying to guess what the world will look like 10 years from now is dumb. Nobody does it well. So just because v1 will have inertia doesn't mean you will actually predict the future more successfully. Instead, you have to figure out how you deal with that inertia. In practice, the reason things have tremendous intertia is because they are often not built to be migrated from or to in a relatively seamless way. Those standards that allow for easy migration tend to see much faster adoption of new versions. Those that don't, the old standards linger even longer.

topspin 4y ago

> Good. We can deal with that in v2.0. There are many, many examples of v2.0 standards that, although better in every respect, never actually supplant v1. v1 has immense inertia. It's not all as willy nilly as it might seem. W3C standardized the parts they could without painting themselves into a corner and wisely factored out the part they couldn't. There is an official W3C hosted registry of methods, each with a specification. They vary hugely in purpose, quality and applicability, all of which will eventually determine their viability. There are at least 3 based on the Bitcoin ('btcr', 'ion' and 'stack') block chain, for example. Which, if any, of these should W3C prefer? The fact of this Cabirian explosion supports the W3C argument. Not selecting some arbitrary subset of these as SHALLs in the v1 standard affords room to discover the benefits and pitfalls given time and iteration. I can understand the viewpoint of Mozilla, Google, et al. I'm sure they'd love to throw a room full of coders at a simple specification and knock out a planetary scale identity system, collect a few billion names and sell all that info to the highest bidders before the next quarterly report. It seems that W3C has other ideas about how this should work.

DannyBee 4y ago
Yes, v1 often has immense inertia. This is true, but it will actually not make you any better at predicting the future, and as i said elsewhere, we are extremely bad at that already. Step into the shoes of a developer 10 years ago, and look the world now. Look ohw much is changed in a way that would affect this stuff. Trying to have successfully anticipated it simply won't work. Instead, you build standards to be easy to transition from/to. That is what enables you to upgrade standards and get reasonable adoption of new versions. While painful, that is the only path that ever works.