4 ms·

> That many complex pieces of software exist does not prove that composition along different boundaries does not work at a larger scale. That logic that you st

• vidarh 5y ago
  > My actual argument was that "none of the non-trivial applications you use daily (...) are composed of a collection of Unix utilities, or the equivalent", which still holds. You made a logical leap to this: > the Unix philosophy does not work for anything but small systems. Which does not follow from the argument you made. > I guess that I could have added the qualifier "popular" to be more precise, but it's still roughly correct. Certainly, there does not exist a popular, featureful tool that is composed entirely out of Unix utilities or the equivalent. That is not relevant to the claim you made. You're now massively moving goalposts. Nothing in your original comment supports the notion that popularity was in anyway relevant to your argument, which in effect was largely implying that doing a single thing means doing a small, trivial thing. 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. 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. > Which, I notice, you didn't name. Why is that? Perhaps because it's not very popular, or because it's not a non-trivial piece of software? I didn't name it because it doesn't have a name. It's my personal editor. I was able to put it together as easily as I did exactly because applying the Unix philosophy meant I did not have to write an editor from scratch, but could avoid writing large chunks of what people usually write, and instead write just the bits that are custom to how I want things to work This is a central part of the Unix philosophy: That providing reusable tools allows you to build on them without reinventing the basics. This goes to the point above that the Unix philosophy is not about avoiding custom code, but about avoiding custom code to do things that can be done with existing tools, and to maximise the ability to reuse tools it helps when your tools have a focus and provide a reasonable complete feature set. The point is not for the tools to be small, but for them to be cohesive whichever size that requires. Popularity is irrelevant to the claim I responded to. That you're now making an entirely different argument does not change that. > The point stands - large systems aren't built using the Unix philosophy - or, none that are popular (I'm sure there exist large systems made using Unix tools, but no one uses them, because they're brittle and slow). Here you are stating two entirely different arguments that are not remotely comparable. A whole lot of large distributed systems are built using the Unix philosophy. I've built and worked on many over my career. The vast majority of my last 25 years have been spent building systems following those principles. That these platforms rarely get published is not proof of their non-existence.
  • throw10920 5y ago
    > 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