4 ms·

This sounds like my nightmare operating system. Reusing the same command to operate on very different kinds of objects is a bad idea. A file is very different f

This sounds like my nightmare operating system. Reusing the same command to operate on very different kinds of objects is a bad idea. A file is very different from a process. A database table is very different from a file. Whenever you try to homogenize operations on different kinds of objects under a single operation name, you inevitably lose flexibility or you have to add a lot of if-then-else statements inside the implementation code which increases cyclomatic complexity and leads to bugs. Also I don't think it makes it easier. What if I want to delete a process but I accidentally end up deleting a file because I mistyped the name of the process (or the file has the same name as the process; which one should be deleted?)? I think we need separate commands because the user needs to be in a different mindset when doing these operations. I'm actually not a huge fan of the Unix philosophy for that reason; you end up with a lot of general purpose commands which work together in theory and you can combine them in an infinite number of ways... But in practice, they are too general and this means that combining them becomes too slow for a lot of scenarios... If commands are too small and too general, you will always end up having to write long sequences of multi-lined commands chained together in order to do anything useful and performance will be bad; you might as well just write C/C++ code.

taffer 7y ago
I would make a distinction between querying and mutating the operating system state. For querying information, I think the idea of representing everything as the same data structure really makes sense. The Unix philosophy or a relational view is perfect for this. However, for more sematically complex things that have possibly surprising side effects, such as starting a service, setting up a new user account, connecting a drive, installing a printer, I think we need separate commands or procedures to encapsulate all the complex behavior.
fouc 7y ago
He probably meant having the same internal interface, it would still be doable to have various aliased commands that call the same interface. As for UNIX philosophy of stringing together lots of general purpose commands to get the desired result - the nice thing about that is you don't need to know programming, and it's very convenient for one off scripting.
- nerdponx 7y ago
  As for UNIX philosophy of stringing together lots of general purpose commands to get the desired result - the nice thing about that is you don't need to know programming, and it's very convenient for one off scripting. I beg to differ. It's a workflow by and for programmers, or at least people who think like programmers.

taffer 7y ago

I would make a distinction between querying and mutating the operating system state. For querying information, I think the idea of representing everything as the same data structure really makes sense. The Unix philosophy or a relational view is perfect for this. However, for more sematically complex things that have possibly surprising side effects, such as starting a service, setting up a new user account, connecting a drive, installing a printer, I think we need separate commands or procedures to encapsulate all the complex behavior.

fouc 7y ago

He probably meant having the same internal interface, it would still be doable to have various aliased commands that call the same interface. As for UNIX philosophy of stringing together lots of general purpose commands to get the desired result - the nice thing about that is you don't need to know programming, and it's very convenient for one off scripting.

nerdponx 7y ago
As for UNIX philosophy of stringing together lots of general purpose commands to get the desired result - the nice thing about that is you don't need to know programming, and it's very convenient for one off scripting. I beg to differ. It's a workflow by and for programmers, or at least people who think like programmers.