8 ms·

This got linked in another front page story. Uncomfortable Truths in Software Engineering. > The Unix philosophy of “do one thing well” doesn’t actually work t

This got linked in another front page story. Uncomfortable Truths in Software Engineering. > The Unix philosophy of “do one thing well” doesn’t actually work that well. Dan Luu explains this better than I could. Usually The Unix Philosophy gets nothing but praise in these parts so I was interested to see a counterpoint.

ReleaseCandidat 5y ago
The 'Unix Haters Book' has some too: https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf
- marcodiego 5y ago
  The UHHB has very few points that are still valid. It is a humorous piece and was written about 3 decades ago. We shouldn't continue citing it as valid criticism.
  - ReleaseCandidat 5y ago
    > The UHHB has very few points that are still valid. I disagree. Yes, nobody uses sendmail anymore, filesystems vastly improved and X isn't a resource hog any more. I've reread it some months ago and the main points still hold. For example the part about `kill`: Most operating systems have a “kill” command. So does Unix. In most operating systems, the kill command kills a process. The Unix implementation is much more general: the “kill” command sends a process a message. This illustrates the first Unix design principle: • Give the user power by making operations fully general. The kill command is very powerful; it lets you send all sorts of messages to processes. For example, one message you can send to a process tells it to kill itself. This message is -9. -9 is, of course, the largest single-digit message, which illustrates another important Unix design principle: • Choose simple names that reflect function.
    - monroeclinton 5y ago
      I don't find the argument about kill convincing. You can use `kill pid` and it will send a SIGTERM signal to the process. The -9 option is only necessary when you want to send a SIGKILL signal. I don't think it is a bad thing that kill gives users the option to choose which signal to send. I only use the -9 option when I want to terminate a process without it being handled.
    - Athas 5y ago
      While I agree that there's much of the UHHB that is still valid (and what's not valid is still funny), I don't think that's a good example. Modern kill allows you to provide the signal name if you wish. I don't think it's a particularly good criticism of kill that it also allows you to use a numeric shorthand if you wish (even if that shorthand is very popular). I think the UUHB is mostly worth reading to understand the absolutely dismal state of proprietary Unix in the 90s. It explains why technical reasons contributed to the growth of both Windows NT and GNU.
xxpor 5y ago
I mean the empirical evidence alone seems point at the Unix Philosophy not actually being popular in practice. GNU tools are much more widely used on boxes humans interact with than BSD/busybox. You don't see everyone trying to figure out how to install all of the suckless tools immediately after installing linux, etc. And then of course we get into systemd and that whole ball of wax. I do think there's a growing split between server like things and desktop like systems that people actually regularly use. For example, Alpine is super popular in containers, not so much on desktops. Same thing with Busybox, but that's more explicitly meant for embedded envs.
- wyager 5y ago
  Software popularity is almost always a historical accident rather than a reflection of users' preferences.
  - ReleaseCandidat 5y ago
    Almost nobody used the original Unix-tools on any Unix (like Irix, Solaris, AIX, HP-UX and Tru64). Everybody installed the GNU tools, that's why after some time every vendor shipped them with their Unix as add-on disks.
    - pjmlp 5y ago
      Not really, because devs would have to put up with what the likes of people like myself actually made available on the servers they had to telnet into for development. The only big UNIX where I actually did install GNU stuff was on Solaris 2.6 via the GNU packages repository, because I was requested to do so. All our HP-UX and Aix boxes used the vendor tooling (including the C compilers).
      - ReleaseCandidat 5y ago
        > Not really, because devs would have to put up with what the likes of people like myself actually made available on the servers they had to telnet into for development. Fortunately that didn't work when you needed 3D graphics hardware. But I guess you worked in a 'server' company, not a graphics (3D or engineering) one? > All our HP-UX and Aix boxes used the vendor tooling (including the C compilers). Of course, GCC was only needed for most of the later (early 2000s) OSS like Mozilla that didn't work with the native compilers because of missing GNU extensions. That's one thing I don't miss - the prices of compilers. SGI took more than 10,000 € for their MipsPro C, C++ and Fortran compilers but without 'advanced' optimization options like auto parallelization and their 'IDE' tools, Developer Workshop. That reminded my of Totalview (a debugger from ???): now Perforce bought them https://totalview.io/ https://totalview.io/
avgcorrection 5y ago
Usually both the Unix Philosophy gets uncritical praise and many people complain about how unstructured shell application data is. The great thing about this essay is that it connects the two dots and finally concludes that “do one thing well” and “text is the universal interface” go together like oil and water.
the_af 5y ago
> The Unix philosophy of “do one thing well” doesn’t actually work that well. Dan Luu explains this better than I could. That quote from the Uncomfortable Truths article is strange because Dan Luu doesn't explain that "it doesn't actually work well". He just explains that the philosophy is not consistently followed, but he is not unhappy with it.
- MisterTea 5y ago
  > He just explains that the philosophy is not consistently followed, but he is not unhappy with it. Which is exactly the reason for the glut of command line options. A great example of following Unix philosophy using a more recent example is the ssh client on plan 9. It is split into three separate programs each with their own man page: ssh(1) for terminal access, sshfs(4) for mounting a remote file tree, and sshnet(4) which imports a remote machines tcp stack. Keep it simple, stupid.
BrazzVuvuzela 5y ago
In years past, some Unix utilities used to do things like silently truncating long lines that were too long for the static buffers used by those tools. The GNU Coding Standards document (originally written in the early 90s I believe) specifically says not to do things like this (GNU's Not Unix, after all..) > For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. https://www.gnu.org/prep/standards/standards.html https://www.gnu.org/prep/standards/standards.html
AceJohnny2 5y ago
Rob Pike, one of Unix's co-creators, and owner of quite a sharp tongue, put it best in a Slashdot interview: "Those days [of the Unix Philosophy] are dead and gone, and the eulogy was delivered by Perl." https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
- fsckboy 5y ago
  ok sure, but unix is still here and perl died there's a subtle thing about perl that's not mentioned often, which is how it borrowed ideas from many other tools and that made perl "intuitive" to learn for people who knew the other tools. But once you're embedded in just perl for awhile, you forget the other tools and then perl's grab-bag of borrowed ideas becomes sort of burdensome, it loses "intuitiveness".
  - anthk 5y ago
    Perl didn't die. Perl superseded awk.
  - AceJohnny2 5y ago
    Only after I had to do some non-trival Bash scripting did I stop hating Perl's syntax. For one thing, at least Perl wasn't as bad as Bash. For another, I now understood where Perl came from! Perl's syntax is a relic of its time, and it blazed a trail for what to do (and what to avoid!) in later scripting languages.
  - oblio 5y ago
    Perl itself died. But Perl's philosophy of batteries included and do almost everything in a single language won. If anything, Perl killed classic Unix and much of the Unix philosophy. Every major modern design looks more like Perl than like Unix: Python, Ruby, PHP, JavaScript, Java, C#, Swift, Go, Rust, etc. They're all "batteries included".
linguae 5y ago
An interesting alternative approach to Unix pipes are systems where everything is an object and where objects can be composed, similar to the idea of function composition in mathematics (e.g., f(g(x)). This can not only be used for command-line applications (for example, PowerShell), but this approach can be taken in graphical-user interfaces. The Smalltalk-80 environment is the ideal substrate for creating such an ecosystem, and Windows has support for implementing such component-based technology, namely (1) Microsoft's OLE (https://docs.microsoft.com/en-us/cpp/mfc/ole-background?view=msvc-170 https://docs.microsoft.com/en-us/cpp/mfc/ole-background?view...), (2) the Component Object Model (https://docs.microsoft.com/en-us/windows/win32/com/the-component-object-model https://docs.microsoft.com/en-us/windows/win32/com/the-compo...), and (3) the .NET Common Language Infrastructure (https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://en.wikipedia.org/wiki/Common_Language_Infrastructure). Back in the mid-1990's Apple once promoted OpenDoc (https://en.wikipedia.org/wiki/OpenDoc https://en.wikipedia.org/wiki/OpenDoc), a standard that was envisioned to support an ecosystem of component-based software, where users could mix and match components to create modular solutions instead of depending on large, monolithic software applications. Here is a nice short video promo from roughly 1994 describing OpenDoc: https://www.youtube.com/watch?v=oFJdjk2rq4E https://www.youtube.com/watch?v=oFJdjk2rq4E. OpenDoc was nixed when Steve Jobs returned to Apple; my opinion for this nixing is because (1) Apple at the time needed to focus on one technical direction (OpenDoc was one of many competing software visions at Apple before Steve Jobs united Apple toward a software vision built on top of OpenStep/Cocoa), and (2) it's hard to promote a component-based software ecosystem when the Mac was on life support and needed support from popular vendors of large, monolithic applications (I'm talking mainly about Adobe and Microsoft) in order for Mac users of these applications to stay on the Mac. I believe this is the same reason why we haven't seen much of a component-based software ecosystem on Windows outside of Microsoft Office's interoperability among its applications: it's easier for software vendors to sell integrated solutions than to sell components that users will have to integrate themselves. I wish the FOSS desktop ecosystem, which doesn't have the same commercial concerns as the world of proprietary software, embraced component-based software beyond Unix pipes. However, the FOSS desktop ecosystem rallied behind KDE and GNOME in the latter half of the 1990's, and thus many of us still rely on large applications like LibreOffice, Firefox, and the GIMP instead of component-based alternatives.

ReleaseCandidat 5y ago

The 'Unix Haters Book' has some too: https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf

marcodiego 5y ago
The UHHB has very few points that are still valid. It is a humorous piece and was written about 3 decades ago. We shouldn't continue citing it as valid criticism.
- ReleaseCandidat 5y ago
  > The UHHB has very few points that are still valid. I disagree. Yes, nobody uses sendmail anymore, filesystems vastly improved and X isn't a resource hog any more. I've reread it some months ago and the main points still hold. For example the part about `kill`: Most operating systems have a “kill” command. So does Unix. In most operating systems, the kill command kills a process. The Unix implementation is much more general: the “kill” command sends a process a message. This illustrates the first Unix design principle: • Give the user power by making operations fully general. The kill command is very powerful; it lets you send all sorts of messages to processes. For example, one message you can send to a process tells it to kill itself. This message is -9. -9 is, of course, the largest single-digit message, which illustrates another important Unix design principle: • Choose simple names that reflect function.
  - monroeclinton 5y ago
    I don't find the argument about kill convincing. You can use `kill pid` and it will send a SIGTERM signal to the process. The -9 option is only necessary when you want to send a SIGKILL signal. I don't think it is a bad thing that kill gives users the option to choose which signal to send. I only use the -9 option when I want to terminate a process without it being handled.
  - Athas 5y ago
    While I agree that there's much of the UHHB that is still valid (and what's not valid is still funny), I don't think that's a good example. Modern kill allows you to provide the signal name if you wish. I don't think it's a particularly good criticism of kill that it also allows you to use a numeric shorthand if you wish (even if that shorthand is very popular). I think the UUHB is mostly worth reading to understand the absolutely dismal state of proprietary Unix in the 90s. It explains why technical reasons contributed to the growth of both Windows NT and GNU.

xxpor 5y ago

I mean the empirical evidence alone seems point at the Unix Philosophy not actually being popular in practice. GNU tools are much more widely used on boxes humans interact with than BSD/busybox. You don't see everyone trying to figure out how to install all of the suckless tools immediately after installing linux, etc. And then of course we get into systemd and that whole ball of wax. I do think there's a growing split between server like things and desktop like systems that people actually regularly use. For example, Alpine is super popular in containers, not so much on desktops. Same thing with Busybox, but that's more explicitly meant for embedded envs.

wyager 5y ago
Software popularity is almost always a historical accident rather than a reflection of users' preferences.
- ReleaseCandidat 5y ago
  Almost nobody used the original Unix-tools on any Unix (like Irix, Solaris, AIX, HP-UX and Tru64). Everybody installed the GNU tools, that's why after some time every vendor shipped them with their Unix as add-on disks.
  - pjmlp 5y ago
    Not really, because devs would have to put up with what the likes of people like myself actually made available on the servers they had to telnet into for development. The only big UNIX where I actually did install GNU stuff was on Solaris 2.6 via the GNU packages repository, because I was requested to do so. All our HP-UX and Aix boxes used the vendor tooling (including the C compilers).
    - ReleaseCandidat 5y ago
      > Not really, because devs would have to put up with what the likes of people like myself actually made available on the servers they had to telnet into for development. Fortunately that didn't work when you needed 3D graphics hardware. But I guess you worked in a 'server' company, not a graphics (3D or engineering) one? > All our HP-UX and Aix boxes used the vendor tooling (including the C compilers). Of course, GCC was only needed for most of the later (early 2000s) OSS like Mozilla that didn't work with the native compilers because of missing GNU extensions. That's one thing I don't miss - the prices of compilers. SGI took more than 10,000 € for their MipsPro C, C++ and Fortran compilers but without 'advanced' optimization options like auto parallelization and their 'IDE' tools, Developer Workshop. That reminded my of Totalview (a debugger from ???): now Perforce bought them https://totalview.io/ https://totalview.io/

avgcorrection 5y ago

Usually both the Unix Philosophy gets uncritical praise and many people complain about how unstructured shell application data is. The great thing about this essay is that it connects the two dots and finally concludes that “do one thing well” and “text is the universal interface” go together like oil and water.

the_af 5y ago

> The Unix philosophy of “do one thing well” doesn’t actually work that well. Dan Luu explains this better than I could. That quote from the Uncomfortable Truths article is strange because Dan Luu doesn't explain that "it doesn't actually work well". He just explains that the philosophy is not consistently followed, but he is not unhappy with it.

MisterTea 5y ago
> He just explains that the philosophy is not consistently followed, but he is not unhappy with it. Which is exactly the reason for the glut of command line options. A great example of following Unix philosophy using a more recent example is the ssh client on plan 9. It is split into three separate programs each with their own man page: ssh(1) for terminal access, sshfs(4) for mounting a remote file tree, and sshnet(4) which imports a remote machines tcp stack. Keep it simple, stupid.

BrazzVuvuzela 5y ago

In years past, some Unix utilities used to do things like silently truncating long lines that were too long for the static buffers used by those tools. The GNU Coding Standards document (originally written in the early 90s I believe) specifically says not to do things like this (GNU's Not Unix, after all..) > For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. https://www.gnu.org/prep/standards/standards.html https://www.gnu.org/prep/standards/standards.html

AceJohnny2 5y ago

Rob Pike, one of Unix's co-creators, and owner of quite a sharp tongue, put it best in a Slashdot interview: "Those days [of the Unix Philosophy] are dead and gone, and the eulogy was delivered by Perl." https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...

fsckboy 5y ago
ok sure, but unix is still here and perl died there's a subtle thing about perl that's not mentioned often, which is how it borrowed ideas from many other tools and that made perl "intuitive" to learn for people who knew the other tools. But once you're embedded in just perl for awhile, you forget the other tools and then perl's grab-bag of borrowed ideas becomes sort of burdensome, it loses "intuitiveness".
- anthk 5y ago
  Perl didn't die. Perl superseded awk.
- AceJohnny2 5y ago
  Only after I had to do some non-trival Bash scripting did I stop hating Perl's syntax. For one thing, at least Perl wasn't as bad as Bash. For another, I now understood where Perl came from! Perl's syntax is a relic of its time, and it blazed a trail for what to do (and what to avoid!) in later scripting languages.
- oblio 5y ago
  Perl itself died. But Perl's philosophy of batteries included and do almost everything in a single language won. If anything, Perl killed classic Unix and much of the Unix philosophy. Every major modern design looks more like Perl than like Unix: Python, Ruby, PHP, JavaScript, Java, C#, Swift, Go, Rust, etc. They're all "batteries included".

linguae 5y ago

An interesting alternative approach to Unix pipes are systems where everything is an object and where objects can be composed, similar to the idea of function composition in mathematics (e.g., f(g(x)). This can not only be used for command-line applications (for example, PowerShell), but this approach can be taken in graphical-user interfaces. The Smalltalk-80 environment is the ideal substrate for creating such an ecosystem, and Windows has support for implementing such component-based technology, namely (1) Microsoft's OLE (https://docs.microsoft.com/en-us/cpp/mfc/ole-background?view=msvc-170 https://docs.microsoft.com/en-us/cpp/mfc/ole-background?view...), (2) the Component Object Model (https://docs.microsoft.com/en-us/windows/win32/com/the-component-object-model https://docs.microsoft.com/en-us/windows/win32/com/the-compo...), and (3) the .NET Common Language Infrastructure (https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://en.wikipedia.org/wiki/Common_Language_Infrastructure). Back in the mid-1990's Apple once promoted OpenDoc (https://en.wikipedia.org/wiki/OpenDoc https://en.wikipedia.org/wiki/OpenDoc), a standard that was envisioned to support an ecosystem of component-based software, where users could mix and match components to create modular solutions instead of depending on large, monolithic software applications. Here is a nice short video promo from roughly 1994 describing OpenDoc: https://www.youtube.com/watch?v=oFJdjk2rq4E https://www.youtube.com/watch?v=oFJdjk2rq4E. OpenDoc was nixed when Steve Jobs returned to Apple; my opinion for this nixing is because (1) Apple at the time needed to focus on one technical direction (OpenDoc was one of many competing software visions at Apple before Steve Jobs united Apple toward a software vision built on top of OpenStep/Cocoa), and (2) it's hard to promote a component-based software ecosystem when the Mac was on life support and needed support from popular vendors of large, monolithic applications (I'm talking mainly about Adobe and Microsoft) in order for Mac users of these applications to stay on the Mac. I believe this is the same reason why we haven't seen much of a component-based software ecosystem on Windows outside of Microsoft Office's interoperability among its applications: it's easier for software vendors to sell integrated solutions than to sell components that users will have to integrate themselves. I wish the FOSS desktop ecosystem, which doesn't have the same commercial concerns as the world of proprietary software, embraced component-based software beyond Unix pipes. However, the FOSS desktop ecosystem rallied behind KDE and GNOME in the latter half of the 1990's, and thus many of us still rely on large applications like LibreOffice, Firefox, and the GIMP instead of component-based alternatives.