3 ms·
It was a horrible idea. The real robustness principle is "Follow the spec".
by thfuran 3y ago
It was a horrible idea. The real robustness principle is "Follow the spec".
- nomel 3y agoI've tried telling users "sorry, your file isn't to spec", and they say "but it works with <competitor>", and that ideology flies right out the window, along with their money.
- pixl97 3y agoThat's when you ask to see their file, then hack <competitors> system.
- ryandrake 3y agoExactly. "Accepting and trying" is how a lot of popular software won their market. Look at HN's favorite media player, VLC. In the past, media player software were horrible, refusing to play all but the most tightly constrained set of allowed containers/codecs. I remember spending the early 2000s trying to get Windows Media Player to play MPEGs by downloading codec packs and trying to cast secret spells into the Windows Registry. Yuck! Then along comes VLC which accepts whatever you throw at it, and that software is basically everywhere now. You can throw line noise at VLC and it will try its best to play something!
- thfuran 3y agoPeople will pay you to do all kinds of terrible not-robust things.
- Joker_vD 3y agoYes, and that's why Postel's law is more of an empirical observation (a law of nature, if you will) on which software survives and which doesn't. You may dislike it but that won't make it go away.
- nomel 3y agoI see it as the opposite, actually. They will pay you for a robust product: one that works for them. They have no care for the technical minutiae of your implementation, because they're just trying to do actually interesting things, with the help of your product. This is the customer perspective.
- silotis 3y agoThe trick is to enforce conformance right from the start in the first implementation of a format. Shipping a product that doesn't interop with the existing tools is a non-starter so the devs will have to fix their shit first. As you say, unfortunately the genie cannot be put back in the bottle for formats that already have defective implementations in the wild.
- riffraff 3y agoThe problem is that unless you restrict everyone else you'll get your own product not to interact with *new" tools too. E.g. you produce valid .wat files, but my software which also outputs those has some bits screwed up. My program can read both .wat but yours can't, but I have 5% market share. Your users complain they sometimes receive files your software can't read while the competitor can. Do you tell them "well that file is invalid, tell whoever sent it to you to change the software they use"? The genie can't stay in the bottle unless you have some sort of certification authority and even that may not be enough (see USB)
- thfuran 3y agoBut the more every actor aims to follow the spec rather than reproduce everyone else's bugs, the less quickly the ecosystem devolves into a horrid tangled mess that's nigh impossible for a new entrant.
- quectophoton 3y ago"So you're saying that I can have an advantage over everyone else if I implement all the spec features, plus one extra feature that adds convenience to our users? And you're saying that by doing this, not only do I gain an advantage over the existing competition, but I also make it more difficult for more competitors to appear? [takes notes]"
- thfuran 3y agoMicrosoft is a few decades ahead of you there.
- jimjimjim 3y agoThis is the answer. The customer does not know. They just want it to work. They may be using something that someone else gave them. The original source system of the file may not be changeable. But most importantly, their boss just wants it to work. or else.