4 ms·

> Well, take a simpler case: A program that takes a lock and then reads a file specified by the user on the command line. I'm having trouble seeing the use cas

by mmt 8y ago

> Well, take a simpler case: A program that takes a lock and then reads a file specified by the user on the command line. I'm having trouble seeing the use case under that Unix Philosophy constraint. I admit I might not be imaginative enough, but a program/utility that would be normally expected to operate on its own locked file (by being asked to do so by the user) still seems incongruous. > it was less code to write, while thus causing every user of the abstraction to have to write tons more code if they want to have correct code. Actually, that's a completely valid design decision and philosophically compatible, even if you happen to find it distasteful. It's one of the (caricatured) tenets of "Worse is Better" which has been credited with the (original) success of Unix over more "correct" competitors http://dreamsongs.com/RiseOfWorseIsBetter.html http://dreamsongs.com/RiseOfWorseIsBetter.html : > Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. > Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct. > Consistency -- the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. > Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. It seems like advisory locking has made a "worse" sacrifice in each category, in favor of the purported benefit. There's even a reference (though I don't recall if it's in that essay, specifically) to making the user do extra coding work for correctness. Of course, there are plenty of critics of "Worse is Better" or the "New Jersey approach", including the author of that essay. However, his whole point is that it improves survivability, which, arguably, was still important to Unix in the 80s and maybe even into the 90s. > not thinking it through. Locks are for coordinating concurrency, the unit of concurrency is the process, so locks are held by processes. Oh, and we have to clean up locks that aren't released by the process! Well, let's do that when the file is closed It's absolutely not thinking every possible future scenario and corner case through, but that, I would argue, is the opposite of "braindead". It worked, especially for the use case you described, which seems perfectly reasonable for early Unix (and adherents to the Unix Philosophy of any era).

zAy0LfpBZLC8mAC 8y ago
> I'm having trouble seeing the use case under that Unix Philosophy constraint. I admit I might not be imaginative enough, but a program/utility that would be normally expected to operate on its own locked file (by being asked to do so by the user) still seems incongruous. That's just bad engineering. "Seems unlikely, therefore we ignore it" is essentially how you create broken corner cases that result in unreliable systems, i.e., braindead. > Actually, that's a completely valid design decision and philosophically compatible, even if you happen to find it distasteful. No, it's not. It's one that people make, that doesn't make it valid, just a reality. > However, his whole point is that it improves survivability, which, arguably, was still important to Unix in the 80s and maybe even into the 90s. That's not a justification for building bad systems, that's only an explanation for why bad systems survive once they have been built. You might as well say that fraud improves survivability. Yeah, under certain circumstances it does, that doesn't mean that winning a market via fraud is in the interest of all market participants or that your product is therefore good, it simply means that you can win against competitors by using fraud. > It's absolutely not thinking every possible future scenario and corner case through, but that, I would argue, is the opposite of "braindead". It's obviously wrong scoping, hence braindead. You don't need to think through every possible future scenario, you simply have to try and formulate the composability semantics of the mechanism and you should notice it's broken. > It worked, especially for the use case you described, which seems perfectly reasonable for early Unix (and adherents to the Unix Philosophy of any era). In which case that philosophy was braindead then?
- mmt 8y ago
  > That's just bad engineering. "Seems unlikely, therefore we ignore it" is essentially how you create broken corner cases that result in unreliable systems, i.e., braindead. I can only assume, then, that your "simple" example wasn't simple at all, but a contrivance to result in such a corner case. You've also confused "we ignore it" with "we consciously decide not to bother with it". > That's not a justification for building bad systems, that's only an explanation for why bad systems survive once they have been built. This is a distinction without a difference. This isn't a moral issue, so "justification" is irrelevant. There are only tradeoffs. Insisting that the design was just bad, broken, unreliable, or braindead, while not even acknowledging the tradeoffs (i.e. ignoring the positives or, instead, calling them negatives) strikes me as disingenuous. > You might as well say that fraud improves survivability. Nope. That's a strawman. > In which case that philosophy was braindead then? I urge you to read the essay and the commentary around "Worse is Better". Otherwise, all this is essentially just a shallow dismissal. You have, in essence, argued in favor of the "MIT method". As I said, this argument was already given, by the original proponents, the mentioned essay's author, and numerous other reasonably well known names in computer science, mostly decades ago. A web search or even just Wikipedia can provide jumping off points.

by mmt 8y ago

zAy0LfpBZLC8mAC 8y ago

> I'm having trouble seeing the use case under that Unix Philosophy constraint. I admit I might not be imaginative enough, but a program/utility that would be normally expected to operate on its own locked file (by being asked to do so by the user) still seems incongruous. That's just bad engineering. "Seems unlikely, therefore we ignore it" is essentially how you create broken corner cases that result in unreliable systems, i.e., braindead. > Actually, that's a completely valid design decision and philosophically compatible, even if you happen to find it distasteful. No, it's not. It's one that people make, that doesn't make it valid, just a reality. > However, his whole point is that it improves survivability, which, arguably, was still important to Unix in the 80s and maybe even into the 90s. That's not a justification for building bad systems, that's only an explanation for why bad systems survive once they have been built. You might as well say that fraud improves survivability. Yeah, under certain circumstances it does, that doesn't mean that winning a market via fraud is in the interest of all market participants or that your product is therefore good, it simply means that you can win against competitors by using fraud. > It's absolutely not thinking every possible future scenario and corner case through, but that, I would argue, is the opposite of "braindead". It's obviously wrong scoping, hence braindead. You don't need to think through every possible future scenario, you simply have to try and formulate the composability semantics of the mechanism and you should notice it's broken. > It worked, especially for the use case you described, which seems perfectly reasonable for early Unix (and adherents to the Unix Philosophy of any era). In which case that philosophy was braindead then?

mmt 8y ago
> That's just bad engineering. "Seems unlikely, therefore we ignore it" is essentially how you create broken corner cases that result in unreliable systems, i.e., braindead. I can only assume, then, that your "simple" example wasn't simple at all, but a contrivance to result in such a corner case. You've also confused "we ignore it" with "we consciously decide not to bother with it". > That's not a justification for building bad systems, that's only an explanation for why bad systems survive once they have been built. This is a distinction without a difference. This isn't a moral issue, so "justification" is irrelevant. There are only tradeoffs. Insisting that the design was just bad, broken, unreliable, or braindead, while not even acknowledging the tradeoffs (i.e. ignoring the positives or, instead, calling them negatives) strikes me as disingenuous. > You might as well say that fraud improves survivability. Nope. That's a strawman. > In which case that philosophy was braindead then? I urge you to read the essay and the commentary around "Worse is Better". Otherwise, all this is essentially just a shallow dismissal. You have, in essence, argued in favor of the "MIT method". As I said, this argument was already given, by the original proponents, the mentioned essay's author, and numerous other reasonably well known names in computer science, mostly decades ago. A web search or even just Wikipedia can provide jumping off points.