8 ms·

Most of these are fine, but U is a massive mistake. The Unix philosophy is fine for tiny systems, but absolutely terrible for building any nontrivial system, b

Most of these are fine, but U is a massive mistake. The Unix philosophy is fine for tiny systems, but absolutely terrible for building any nontrivial system, because it causes the complexity of the system to grow super-linearly with the number of features - O(n^2), in big-O notation, where n is the intrinsic complexity of the application (roughly, the features you want) and the big-O measures the total complexity of the application. Why? Super quick breakdown: code has to be broken up into modules in order to prevent human brains from exploding, if the modules are too small then inter-module communication complexity dominates (because you then need a large number of modules to implement your features), if the modules are too large than intra-module implementation complexity dominates, and the Unix philosophy requires erring on the size of too-small modules. For empirical evidence: none of the non-trivial applications you use daily (bash, firefox, chrome, windows, linux, macos, blender, krita, gcc, cargo, llvm, npm, node, vim, emacs, vscode, sublime - whatever you want) are composed of a collection of Unix utilities, or the equivalent (flat program hierarchy consisting of thousands of call sites to hundreds of tiny functions). The evidence is very clear: the Unix philosophy does not work for anything but small systems.

zozbot234 5y ago
Modules can be built compositionally from smaller modules, even in the *nix shell - that's what a shell script is! Similarly, libraries can depend from other lower-level libraries. No flat structure is required, hence no huge increase in either implementation or communication complexity.
jpitz 5y ago
Contrary opinion: the Unix philosophy advocates a level of granularity larger than you posit - grep has a single responsibility, but is not a "tiny function"
lambic 5y ago
The "do one thing and do it well" philosophy can be taken to bad extremes, but the tools you list mostly fit the philosophy as it was intended. Vim is a text editor, it does that one thing and does it well. Firefox is a web browser, it does that one thing and does it well, notwithstanding attempts to cram everything into web browsing.
- thaeli 5y ago
  And emacs is.. well, okay, that one's not a good example.
  - yoyohello13 5y ago
    Emacs follows the UNIX philosophy. All it does is interpret elisp.
- bvirb 5y ago
  This sounds like the same discussion I always see about the SRP. I think the root of it is that whether you're following the SRP can always be true, depending on how you're looking at your code. If the one thing your code is supposed to do is "run the whole application" then putting everything into one file called "Application" sounds just fine. If the one thing your code is supposed to do is "add 2+2" then abstracting a module that only adds 2+2 seems just fine. I always found the SRP too vague to be useful for actual decision making, it seems to just lead to arguments where everybody (and nobody) is correct. "Unix philosophy" sounds like it is just about as vague, or am I just really missing something that everyone else gets?
  - splittingTimes 5y ago
    I really liked Dan's reasoning around SRP "SRP mandates that you separate the rendering and business logic of the component. As a developer, having these living in different places leads to an administrative chore of chaining identical fields together. The greater risk is that this may be a premature optimisation preventing a more natural separation of concerns emerging as the codebase grows, and as components emerge that “do one thing well” and that are better suited to the domain model of the problem space."
- charcircuit 5y ago
  >Firefox is a web browser, it does that one thing and does it well Can't you justify anything that way? You called easily say that the rendering engine, JavaScript engine, etc should all be split up into programs that do that well.
Kinrany 5y ago
"Do one thing" is too short to mean anything. Originally it's about avoiding the quadratic explosion of the number of things that must be implemented. The method is to replace M * N separate pieces of code with - a single extra X thing - M + N pieces of code - a way to compose these M + N pieces of code to get the M * N you wanted in the first place
- karma_fountain 5y ago
  I think what you describe is preferable and is how I like to code in general, but then I find that the complexity comes from how these things communicate. It's not actually true in general that the whole is greater than the sum of the parts, but it's good to have a system that possess this property.
  - vidarh 5y ago
    But that complexity is even larger without this encapsulation into components. Reducing the complexity by reducing the potential communications surface is a large part of the point.
vidarh 5y ago
This logic is invalid. That many complex pieces of software exist does not prove that composition along different boundaries does not work at a larger scale. I've built large platforms out of small, simple components. Works just fine. The text editor I use daily is composed of small, simple components. Both internally, and by separating out many things most editors do internally: File selection, theme selection, and others is delegated to rofi, for example. Splitting into frames is delegated to my tiling wm. Separating this functionality out changes where the boundaries are, and how to reuse them, not the existence of them.
- throw10920 5y ago
  > 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 stated is invalid; you strawmanned my argument. 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. 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. > The text editor I use daily is composed of small, simple components. 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? 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).
  - 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.

zozbot234 5y ago

Modules can be built compositionally from smaller modules, even in the *nix shell - that's what a shell script is! Similarly, libraries can depend from other lower-level libraries. No flat structure is required, hence no huge increase in either implementation or communication complexity.

jpitz 5y ago

Contrary opinion: the Unix philosophy advocates a level of granularity larger than you posit - grep has a single responsibility, but is not a "tiny function"

lambic 5y ago

The "do one thing and do it well" philosophy can be taken to bad extremes, but the tools you list mostly fit the philosophy as it was intended. Vim is a text editor, it does that one thing and does it well. Firefox is a web browser, it does that one thing and does it well, notwithstanding attempts to cram everything into web browsing.

thaeli 5y ago
And emacs is.. well, okay, that one's not a good example.
- yoyohello13 5y ago
  Emacs follows the UNIX philosophy. All it does is interpret elisp.
bvirb 5y ago
This sounds like the same discussion I always see about the SRP. I think the root of it is that whether you're following the SRP can always be true, depending on how you're looking at your code. If the one thing your code is supposed to do is "run the whole application" then putting everything into one file called "Application" sounds just fine. If the one thing your code is supposed to do is "add 2+2" then abstracting a module that only adds 2+2 seems just fine. I always found the SRP too vague to be useful for actual decision making, it seems to just lead to arguments where everybody (and nobody) is correct. "Unix philosophy" sounds like it is just about as vague, or am I just really missing something that everyone else gets?
- splittingTimes 5y ago
  I really liked Dan's reasoning around SRP "SRP mandates that you separate the rendering and business logic of the component. As a developer, having these living in different places leads to an administrative chore of chaining identical fields together. The greater risk is that this may be a premature optimisation preventing a more natural separation of concerns emerging as the codebase grows, and as components emerge that “do one thing well” and that are better suited to the domain model of the problem space."
charcircuit 5y ago
>Firefox is a web browser, it does that one thing and does it well Can't you justify anything that way? You called easily say that the rendering engine, JavaScript engine, etc should all be split up into programs that do that well.

Kinrany 5y ago

"Do one thing" is too short to mean anything. Originally it's about avoiding the quadratic explosion of the number of things that must be implemented. The method is to replace M * N separate pieces of code with - a single extra X thing - M + N pieces of code - a way to compose these M + N pieces of code to get the M * N you wanted in the first place

karma_fountain 5y ago
I think what you describe is preferable and is how I like to code in general, but then I find that the complexity comes from how these things communicate. It's not actually true in general that the whole is greater than the sum of the parts, but it's good to have a system that possess this property.
- vidarh 5y ago
  But that complexity is even larger without this encapsulation into components. Reducing the complexity by reducing the potential communications surface is a large part of the point.

vidarh 5y ago

This logic is invalid. That many complex pieces of software exist does not prove that composition along different boundaries does not work at a larger scale. I've built large platforms out of small, simple components. Works just fine. The text editor I use daily is composed of small, simple components. Both internally, and by separating out many things most editors do internally: File selection, theme selection, and others is delegated to rofi, for example. Splitting into frames is delegated to my tiling wm. Separating this functionality out changes where the boundaries are, and how to reuse them, not the existence of them.

throw10920 5y ago
> 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 stated is invalid; you strawmanned my argument. 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. 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. > The text editor I use daily is composed of small, simple components. 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? 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).
- 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.