3 ms·

> The Unix philosophy lays emphasis on building software that is simple and extensible. Each piece of software must do one thing and do it well. But, you see…

> The Unix philosophy lays emphasis on building software that is simple and extensible. Each piece of software must do one thing and do it well. But, you see… his first example shows how the ‘git log’ doesn’t only show the log, but receives a flag to output arbitrary information according to the format string, and ‘uniq’ doesn’t only show unique entries, but receives a flag to count entries. I would say these are not great examples of “do one thing”, and taken literally, the Unix philosophy would require much more shell script gymnastic to do simple tasks.

uvdn7 4y ago
Exactly. The definition of “one thing” is unclear. One house is one thing, which also has a thousand things in it. Car is does the “one thing” — driving, but steering is arguably a thing as well.
- astrobe_ 4y ago
  Don't play dumb. When you can describe the function with one simple sentence, it is likely that it does one thing. Cars transport their passengers. The fact that performing this action involves complex processes doesn't matter. Just like a math theorem can be short and say just one thing and be extremely useful, but its demonstration could require many steps. The idea behind the Unix philosophy is not simplicity of implementation - on the contrary many little Unix tools are complex under the hood because they try to do their thing optimally - but modularity. "Do one thing and do it well" to avoid functional overlap. That's simply an obvious and right thing to do in general. However this is not a principle easy to follow, because of unrelated concerns like stuffing your resume with impressive stuff - the problem with "simple" is that it is often confused with "easy" - or making things than can be sold - simplicity doesn't sell, "powerful" (as in "I have no idea what's the purpose of this does and I don't need that thing, but it's good to have 'just in case'") does.
pjmlp 4y ago
That philosophy tends to be cargo cult by those that never used commercial UNIXes. I use UNIX systems since 1993, starting with Xenix, no idea when that started to be something that some people actually believe it happens.
NackerHughes 4y ago
This is a well-known problem of Unix (and software in general) - the original tools have suffered 'feature creep' and expanded far beyond their original intended capabilities. Discussed here on the venerable cat-v website, which is itself named after this very phenomenon: http://harmful.cat-v.org/cat-v/ http://harmful.cat-v.org/cat-v/ It's difficult to know where/when to draw the line though. I went through a phase of being a massive Unix fanboy but found that if you follow the philosophy too strictly, you end up with a tonne of disparate 'tools' that you have to string together several of just to do anything useful. If you have a script that e.g. loops over a list of files, you might have to spawn a large number of processes for every single item in the list, for functionality that feels like it should be built into one program (but if you add one extra feature behind a flag, then there's no reason we shouldn't add another little extra feature behind a flag, and that's how feature creep happens!). Not only that, but once you start stringing together various Unix utilities, the expected output of each becomes set in stone (even if the output is just a single line of tab-separated numbers with no obvious meaning, e.g. `wc`). Plain text can be a lot more fragile than Unix fans would like to admit. You could add an option to a program to present the output in a different/better format if needed, but then that's another flaggie that could be better handled by a separate utility... (e.g. instead of an 'output as json' flag, why not have a 'convert input to json' utility that we can pipe the output through?) In time, I've come to use a mix of single-purpose Unix tools with all their assorted flags, along with monolithic one-man-band tools (e.g. `find` - I have very little trust in piping things through xargs sh -c "run two commands on \"\$filename\" and please don"'"'"t fuck up quotes in \"\$filename\"" - or is it {}? or "{}"? or \"{}\"? or \{\}? You get the picture). Piping stuff together is good for when you're writing shell one-liners and making it up as you go along / as needed, but for anything more than that where a script file is needed, these days I'm more inclined to rewrite it in a 'kitchen sink' language such as PHP or Perl.
deleted 4y ago
[deleted]

uvdn7 4y ago

Exactly. The definition of “one thing” is unclear. One house is one thing, which also has a thousand things in it. Car is does the “one thing” — driving, but steering is arguably a thing as well.

astrobe_ 4y ago
Don't play dumb. When you can describe the function with one simple sentence, it is likely that it does one thing. Cars transport their passengers. The fact that performing this action involves complex processes doesn't matter. Just like a math theorem can be short and say just one thing and be extremely useful, but its demonstration could require many steps. The idea behind the Unix philosophy is not simplicity of implementation - on the contrary many little Unix tools are complex under the hood because they try to do their thing optimally - but modularity. "Do one thing and do it well" to avoid functional overlap. That's simply an obvious and right thing to do in general. However this is not a principle easy to follow, because of unrelated concerns like stuffing your resume with impressive stuff - the problem with "simple" is that it is often confused with "easy" - or making things than can be sold - simplicity doesn't sell, "powerful" (as in "I have no idea what's the purpose of this does and I don't need that thing, but it's good to have 'just in case'") does.

pjmlp 4y ago

That philosophy tends to be cargo cult by those that never used commercial UNIXes. I use UNIX systems since 1993, starting with Xenix, no idea when that started to be something that some people actually believe it happens.

NackerHughes 4y ago

This is a well-known problem of Unix (and software in general) - the original tools have suffered 'feature creep' and expanded far beyond their original intended capabilities. Discussed here on the venerable cat-v website, which is itself named after this very phenomenon: http://harmful.cat-v.org/cat-v/ http://harmful.cat-v.org/cat-v/ It's difficult to know where/when to draw the line though. I went through a phase of being a massive Unix fanboy but found that if you follow the philosophy too strictly, you end up with a tonne of disparate 'tools' that you have to string together several of just to do anything useful. If you have a script that e.g. loops over a list of files, you might have to spawn a large number of processes for every single item in the list, for functionality that feels like it should be built into one program (but if you add one extra feature behind a flag, then there's no reason we shouldn't add another little extra feature behind a flag, and that's how feature creep happens!). Not only that, but once you start stringing together various Unix utilities, the expected output of each becomes set in stone (even if the output is just a single line of tab-separated numbers with no obvious meaning, e.g. `wc`). Plain text can be a lot more fragile than Unix fans would like to admit. You could add an option to a program to present the output in a different/better format if needed, but then that's another flaggie that could be better handled by a separate utility... (e.g. instead of an 'output as json' flag, why not have a 'convert input to json' utility that we can pipe the output through?) In time, I've come to use a mix of single-purpose Unix tools with all their assorted flags, along with monolithic one-man-band tools (e.g. `find` - I have very little trust in piping things through xargs sh -c "run two commands on \"\$filename\" and please don"'"'"t fuck up quotes in \"\$filename\"" - or is it {}? or "{}"? or \"{}\"? or \{\}? You get the picture). Piping stuff together is good for when you're writing shell one-liners and making it up as you go along / as needed, but for anything more than that where a script file is needed, these days I'm more inclined to rewrite it in a 'kitchen sink' language such as PHP or Perl.

deleted 4y ago

[deleted]