> 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).
> 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.
Wut? Explanations are the same thing as justifications? I think you have to explain ...
> This isn't a moral issue, so "justification" is irrelevant.
Actually, it is?
> 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.
There probably were no benefits, other than for the people implementing the kernel, as explained earlier.
> Nope. That's a strawman.
So, what am I misrepresenting then?
> I urge you to read the essay and the commentary around "Worse is Better". Otherwise, all this is essentially just a shallow dismissal.
Yeah, thanks, it doesn't make sense as a justification, only as an explanation.
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?