5 ms·

That's the first design-related documentation I've seen presented, so thank you. However, it's merely an indictment of the POSIX standards process and sheds no

by mmt 8y ago

That's the first design-related documentation I've seen presented, so thank you. However, it's merely an indictment of the POSIX standards process and sheds no light on why the AT&T implementation was the way it was in the first place. I keep reading what, to me (essentially an outsider with no horse in the race), sound like either hyperboles at worst ("brain-dead", "really stupid", "no excuse") and arguments advocating the MIT Method (of "Worse is Better" fame) at best. It tends to beg the question, "If it's so horrible, why did anyone bother to implement it that way or use it once it was there?" I'd expect, if it's actually as broken as everyone makes it out to be, that it would be worse than nothing and would get no use. Apparently, the major db vendors didn't bother, at least at the time, but that could well be because there was no reliable [1] cross-platform option. So, again, how about some actual, contemporaneous evidence of the original design process, for a fair, contextual critique? [1] i.e. reliable or good enough, not reliable in the sense of implementation correctness covering all corner cases, as seems to be demanded by certain commenters and the MIT Method in general.

zAy0LfpBZLC8mAC 8y ago
What would falsify your position? Is there any evidence that you would not reject with "but maybe it was good enough"? If I presented a case where a worker was killed because of this locking mechanism, wouldn't you just say "but maybe it prevented the meltdown of a nuclear reactor, so it was a net positive vs. no locking at all, therefore, it was the right thing to do"?
- mmt 8y ago
  I'm not sure you actually understand my position, which has nothing to do with which philosophy is "right" or "better", but, rather, that the one you seem to object to so strenuously on moral grounds, both existed and was a valid engineering consideration/strategy at the time. To falsify it, you would merely need documentation that such a philosophy was not a consideration in this design. If it's falsified, then there may well be something new to be learned about design and mistakes to be avoided. Otherwise, it's just another example of "Worse Is Better" and isn't worth the effort.
  - zAy0LfpBZLC8mAC 8y ago
    > both existed and was a valid engineering consideration/strategy at the time. Please define what you mean by "valid". > To falsify it, you would merely need documentation that such a philosophy was not a consideration in this design. Well, then I probably don't care? I care whether it was a bad idea, not whether it was a bad idea coming from a bad philosophy or a bad idea standing on its own.
    - mmt 8y ago
      > Well, then I probably don't care? I care whether it was a bad idea, not whether it was a bad idea coming from a bad philosophy or a bad idea standing on its own. If your goal is to prevent such a "bad idea" in the future, then not caring could easily work against you. You'd end up having to expend energy challenging each bad idea on its own, possibly failing even to make inroads because there's a bad philosophy that makes it seem like a good idea (maybe even obviously so, rendering your challenge easily dismissed and a wasted effort). Instead, if you focus your energy on challenging the bad philosophy, you both get to the heart of the matter right away, and you cover all the new bad ideas it enables all at once (and even ahead of time). You also won't have to start from scratch, as the philosophy, unlike every new bad idea, isn't unique, and there's likely plenty of literature out there already that you can use as ammunition.
      - zAy0LfpBZLC8mAC 8y ago
        Well, yeah, of course I care. But not for the determination of whether a bad idea is bad. This may be an instance of worse is better, but it is a bad idea regardless, and thus at best an additional piece of evidence against the philosophy.
  - Dylan16807 8y ago
    A hacky implementation can be simultaneously good enough for some users and also completely unacceptable for a standard. It's not worse than nothing, sure. If you use it exactly as expected, and only have one logical user of a file in each process, it does an acceptable job. But in the context of what it's supposed to do, be a generic locking mechanism, it's horrifically broken. So I'll summarize this way: It's completely okay that they wrote this code, as a "version 0.2". But there's no excuse for presenting it as finished code, with reasonable semantics. It's not hyperbole to say that.

by mmt 8y ago

zAy0LfpBZLC8mAC 8y ago

What would falsify your position? Is there any evidence that you would not reject with "but maybe it was good enough"? If I presented a case where a worker was killed because of this locking mechanism, wouldn't you just say "but maybe it prevented the meltdown of a nuclear reactor, so it was a net positive vs. no locking at all, therefore, it was the right thing to do"?

mmt 8y ago
I'm not sure you actually understand my position, which has nothing to do with which philosophy is "right" or "better", but, rather, that the one you seem to object to so strenuously on moral grounds, both existed and was a valid engineering consideration/strategy at the time. To falsify it, you would merely need documentation that such a philosophy was not a consideration in this design. If it's falsified, then there may well be something new to be learned about design and mistakes to be avoided. Otherwise, it's just another example of "Worse Is Better" and isn't worth the effort.
- zAy0LfpBZLC8mAC 8y ago
  > both existed and was a valid engineering consideration/strategy at the time. Please define what you mean by "valid". > To falsify it, you would merely need documentation that such a philosophy was not a consideration in this design. Well, then I probably don't care? I care whether it was a bad idea, not whether it was a bad idea coming from a bad philosophy or a bad idea standing on its own.
  - mmt 8y ago
    > Well, then I probably don't care? I care whether it was a bad idea, not whether it was a bad idea coming from a bad philosophy or a bad idea standing on its own. If your goal is to prevent such a "bad idea" in the future, then not caring could easily work against you. You'd end up having to expend energy challenging each bad idea on its own, possibly failing even to make inroads because there's a bad philosophy that makes it seem like a good idea (maybe even obviously so, rendering your challenge easily dismissed and a wasted effort). Instead, if you focus your energy on challenging the bad philosophy, you both get to the heart of the matter right away, and you cover all the new bad ideas it enables all at once (and even ahead of time). You also won't have to start from scratch, as the philosophy, unlike every new bad idea, isn't unique, and there's likely plenty of literature out there already that you can use as ammunition.
    - zAy0LfpBZLC8mAC 8y ago
      Well, yeah, of course I care. But not for the determination of whether a bad idea is bad. This may be an instance of worse is better, but it is a bad idea regardless, and thus at best an additional piece of evidence against the philosophy.
- Dylan16807 8y ago
  A hacky implementation can be simultaneously good enough for some users and also completely unacceptable for a standard. It's not worse than nothing, sure. If you use it exactly as expected, and only have one logical user of a file in each process, it does an acceptable job. But in the context of what it's supposed to do, be a generic locking mechanism, it's horrifically broken. So I'll summarize this way: It's completely okay that they wrote this code, as a "version 0.2". But there's no excuse for presenting it as finished code, with reasonable semantics. It's not hyperbole to say that.