4 ms·

> Which does not follow from the argument you made. It absolutely does follow - the facts that you can't name a single popular non-trivial utility that is impl

> Which does not follow from the argument you made. It absolutely does follow - the facts that you can't name a single popular non-trivial utility that is implemented using the Unix philosophy, and that none of the above applications I listed are implemented using it, are strong evidence that it doesn't "work". Let me clarify what "work" means here: it means that it is a software design philosophy that is repeatably effective, scales to large systems, and quickly produces high-quality software. It clearly does not mean "you are able to design a piece of software using it", because you can design a large piece of software using unstructured assembly-language and get it to function, assuming an infinite amount of resources. A design strategy "working" means that it is effective. So, the fact that there aren't any reasonably-popular counterexamples means that the Unix philosophy doesn't work for building medium-sized (and up) software systems, because if it worked, it could be repeatedly used to build them. > Nothing in your original comment supports the notion that popularity was in anyway relevant to your argument It should be pretty obvious that if someone builds a piece of software with the Unix philosophy but then doesn't tell anyone about it, then it can't be used as a piece of evidence for this argument, because neither of us will know about it. It should also be pretty obvious that if someone claims to build a large piece of software with the Unix philosophy but nobody uses it, that's a strong indicator that the software is deficient in some way, and therefore that you can't claim that it indicates that the Unix design philosophy "works" unless you examine it carefully. Therefore, it should be pretty obvious that popularity is relevant. > largely implying that doing a single thing means doing a small, trivial thing That's because it's true. If you're doing a big thing, then you're not doing "a single thing" anymore, because your large task is composed of smaller sub-tasks, which the Unix philosophy says that need to be separate programs. Saying that Windows "does one thing" and that that thing is "general computing things" is pretty obviously wrong, for instance. > The fact that you're suggesting that a criteria would be that such a tool need be composed entirely of "Unix utilities or the equivalent" suggests you miss the point of arguing for such tools. The topic under discussion is whether the Unix philosophy can be productively applied to build large systems. If there doesn't exist a tool that is build entirely out of "Unix utilities or the equivalent", then it means that the Unix philosophy is just bad at that thing. It doesn't matter if I "miss the point" because I'm only interested in building large systems, and that's the only thing I'm interested in discussing. > Part of the point is to have composable, reusable tools, not to reject using additional code when building something else, but to avoid having to write the common parts over and over. "Write reusable software" is a basic and widely-accepted tenet of software engineering. The Unix philosophy is different, because it specifically requires that your modules be separate programs that communicate using text streams[1]. That is the thing about the Unix philosophy that's both unique and bad. I'm not arguing against modularity in software engineering - I'm arguing against the Unix philosophy's specific implementation of it. Finally, you wrap up your comment with fallacies that because just because someone did build something with the Unix philosophy, that means it works - see my earlier point that it doesn't "work" unless you can repeatedly and effectively apply the principle, and that if the artifacts aren't visible or popular, that's a strong indicator that they're deficient...and if all of the artifacts produced using a design philosophy are deficient, then what does that say about the philosophy? (tl;dr - if your evidence for the effectiveness of Unix is that you've seen a bunch of unnamed, non-public systems that I oh so conveniently can't inspect myself, then you don't really have any evidence at all) [1] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy

vidarh 5y ago
> It absolutely does follow - the facts that you can't name a single popular non-trivial utility that is implemented using the Unix philosophy, and that none of the above applications I listed are implemented using it, are strong evidence that it doesn't "work". Doesn't work like that. This is a pointless discussion, as you're trying to infer something not even by lack of existence, but from lack of public popularity. Logic does not work this way. > It should be pretty obvious that if someone builds a piece of software with the Unix philosophy but then doesn't tell anyone about it, then it can't be used as a piece of evidence for this argument, because neither of us will know about it. That is true, but ignoring the fact that I do know of such examples, this is irrelevant as arguing that it is not possible requires justifying why it is not possible, not pointing to your purported absence of evidence that it is possible. > It should also be pretty obvious that if someone claims to build a large piece of software with the Unix philosophy but nobody uses it, that's a strong indicator that the software is deficient in some way, and therefore that you can't claim that it indicates that the Unix design philosophy "works" unless you examine it carefully. Your conclusion does not follow from your argument. > That's because it's true. If you're doing a big thing, then you're not doing "a single thing" anymore, because your large task is composed of smaller sub-tasks, which the Unix philosophy says that need to be separate programs. Saying that Windows "does one thing" and that that thing is "general computing things" is pretty obviously wrong, for instance. This, to me just demonstrates that you don't understand the point of the argument. The point is about cohesion. This kind of pedantic interpretation of "a single thing" taken to it's full extent would mean no programs longer than a single instruction. Clearly that is not the point. Clearly the fact that tools generally accepted as standard unix tools includes multiple Turing-complete tools illustrates that the intent is not this kind of ultimate reductionist thinking. > The topic under discussion is whether the Unix philosophy can be productively applied to build large systems. If there doesn't exist a tool that is build entirely out of "Unix utilities or the equivalent", then it means that the Unix philosophy is just bad at that thing. Your conclusion does not follow from your argument. > That is the thing about the Unix philosophy that's both unique and bad. I'm not arguing against modularity in software engineering - I'm arguing against the Unix philosophy's specific implementation of it. Your original argument was premised on arguing that communication between components would cause a combinatorical explosion. That's not something affected by the specific Unix approach. In other words: You're again trying to change the argument into something very different from original claim. > Finally, you wrap up your comment with fallacies that because just because someone did build something with the Unix philosophy, that means it work - see my earlier point that it doesn't "work" unless you can repeatedly and effectively apply the principle, and that if the artifacts aren't visible or popular, that's a strong indicator that they're deficient...and if all of the artifacts produced using a design philosophy are deficient, then what does that say about the philosophy? Again, your conclusions do not follow from your arguments. > (tl;dr - if your evidence for the effectiveness of Unix is that you've seen a bunch of unnamed, non-public systems that I oh so conveniently can't inspect myself, then you don't really have any evidence at all) This would be relevant if you'd supported your arguments in a logically sound way so that there was something meaningful to refute. As it stands, my direct personal experience serves to explain why I have no reason to believe your unsupported arguments, as I've seen first hand that you're wrong. Whether or not you choose to believe that is of no consequence to me.

vidarh 5y ago

> It absolutely does follow - the facts that you can't name a single popular non-trivial utility that is implemented using the Unix philosophy, and that none of the above applications I listed are implemented using it, are strong evidence that it doesn't "work". Doesn't work like that. This is a pointless discussion, as you're trying to infer something not even by lack of existence, but from lack of public popularity. Logic does not work this way. > It should be pretty obvious that if someone builds a piece of software with the Unix philosophy but then doesn't tell anyone about it, then it can't be used as a piece of evidence for this argument, because neither of us will know about it. That is true, but ignoring the fact that I do know of such examples, this is irrelevant as arguing that it is not possible requires justifying why it is not possible, not pointing to your purported absence of evidence that it is possible. > It should also be pretty obvious that if someone claims to build a large piece of software with the Unix philosophy but nobody uses it, that's a strong indicator that the software is deficient in some way, and therefore that you can't claim that it indicates that the Unix design philosophy "works" unless you examine it carefully. Your conclusion does not follow from your argument. > That's because it's true. If you're doing a big thing, then you're not doing "a single thing" anymore, because your large task is composed of smaller sub-tasks, which the Unix philosophy says that need to be separate programs. Saying that Windows "does one thing" and that that thing is "general computing things" is pretty obviously wrong, for instance. This, to me just demonstrates that you don't understand the point of the argument. The point is about cohesion. This kind of pedantic interpretation of "a single thing" taken to it's full extent would mean no programs longer than a single instruction. Clearly that is not the point. Clearly the fact that tools generally accepted as standard unix tools includes multiple Turing-complete tools illustrates that the intent is not this kind of ultimate reductionist thinking. > The topic under discussion is whether the Unix philosophy can be productively applied to build large systems. If there doesn't exist a tool that is build entirely out of "Unix utilities or the equivalent", then it means that the Unix philosophy is just bad at that thing. Your conclusion does not follow from your argument. > That is the thing about the Unix philosophy that's both unique and bad. I'm not arguing against modularity in software engineering - I'm arguing against the Unix philosophy's specific implementation of it. Your original argument was premised on arguing that communication between components would cause a combinatorical explosion. That's not something affected by the specific Unix approach. In other words: You're again trying to change the argument into something very different from original claim. > Finally, you wrap up your comment with fallacies that because just because someone did build something with the Unix philosophy, that means it work - see my earlier point that it doesn't "work" unless you can repeatedly and effectively apply the principle, and that if the artifacts aren't visible or popular, that's a strong indicator that they're deficient...and if all of the artifacts produced using a design philosophy are deficient, then what does that say about the philosophy? Again, your conclusions do not follow from your arguments. > (tl;dr - if your evidence for the effectiveness of Unix is that you've seen a bunch of unnamed, non-public systems that I oh so conveniently can't inspect myself, then you don't really have any evidence at all) This would be relevant if you'd supported your arguments in a logically sound way so that there was something meaningful to refute. As it stands, my direct personal experience serves to explain why I have no reason to believe your unsupported arguments, as I've seen first hand that you're wrong. Whether or not you choose to believe that is of no consequence to me.