4 ms·

Honest question: does the Unix philosophy apply to all kinds of software? I am curious to know if it's fair to compare typical Unix software (CLI-based, text-b

Honest question: does the Unix philosophy apply to all kinds of software? I am curious to know if it's fair to compare typical Unix software (CLI-based, text-based --- usually system software is what comes to mind) with application software (Word processing, enterprise software, etc).

oconnore 16y ago
I think composition turns into extensibility when you start working on larger programs. For example, you cannot pipe the output of Vim or Emacs into another program, but you can write 100 lines of Python/Lisp/Lua/Perl/etc. that will let one application talk to the other. Other applications see themselves as a walled garden, and may allow extension within the program, but make it difficult for communication to occur between programs, often by not exposing enough state, not documenting the interface, or not providing any scripting at all.
- lurker14 16y ago
  While not a literal "pipe", the $EDITOR and $VISUAL shell conventions are pretty much the same concept applied to larger programs. And of course, which I think you were saying with your comment on extensibility, vim and emacs are well-designed for sending content out to a shell for processing (spell-check is a common example) and retrieving the results. ("!!" in vim)
zdw 16y ago
External libraries and function calls that encapsulate functionality are the equivalent concept in GUI land. For example, it would totally suck to have to write the entire GUI for file selection, and nobody does it if they're smart - they just call a function, and get back a file handle or path. The problem is programs that try to reinvent the wheel. How many file selectors have you seen that are "custom" in some way and thus break convention?
tbrownaw 16y ago
It's about writing modules/extensions for an existing system. Traditional Unix programs make your shell environment work better. Adblock Plus, Perspectives, Tree Style Tab, etc, make my Iceweasel work better. mod_rewrite, mod_php, etc, make Apache work better. The "text streams" part is specific to Unix, because files and pipes are the defining feature of that environment. The other parts are probably universal across any extensible system.
dexen 16y ago
It does to the examples you gave. You get better output quicker -- a neatly formatted PDF -- with CLI tools like LaTeX or troff (they work as a pipe of filters), than with a WYSIWYG like MS Word. You get more relevant data quicker with SQL querying a Data Warehouse than via some GUI front-end that only lets you use some opaque, pre-defined queries. GUI is meant to flatten the learning curve; CLI is meant to let you unleash power of tools you know well. GUI may shine when you do a task once in a blue moon, but CLI is the choice for frequent use. On the other hand, I've never seen any good CLI approach to browsing the web ;-)

oconnore 16y ago

I think composition turns into extensibility when you start working on larger programs. For example, you cannot pipe the output of Vim or Emacs into another program, but you can write 100 lines of Python/Lisp/Lua/Perl/etc. that will let one application talk to the other. Other applications see themselves as a walled garden, and may allow extension within the program, but make it difficult for communication to occur between programs, often by not exposing enough state, not documenting the interface, or not providing any scripting at all.

lurker14 16y ago
While not a literal "pipe", the $EDITOR and $VISUAL shell conventions are pretty much the same concept applied to larger programs. And of course, which I think you were saying with your comment on extensibility, vim and emacs are well-designed for sending content out to a shell for processing (spell-check is a common example) and retrieving the results. ("!!" in vim)

zdw 16y ago

External libraries and function calls that encapsulate functionality are the equivalent concept in GUI land. For example, it would totally suck to have to write the entire GUI for file selection, and nobody does it if they're smart - they just call a function, and get back a file handle or path. The problem is programs that try to reinvent the wheel. How many file selectors have you seen that are "custom" in some way and thus break convention?

tbrownaw 16y ago

It's about writing modules/extensions for an existing system. Traditional Unix programs make your shell environment work better. Adblock Plus, Perspectives, Tree Style Tab, etc, make my Iceweasel work better. mod_rewrite, mod_php, etc, make Apache work better. The "text streams" part is specific to Unix, because files and pipes are the defining feature of that environment. The other parts are probably universal across any extensible system.

dexen 16y ago

It does to the examples you gave. You get better output quicker -- a neatly formatted PDF -- with CLI tools like LaTeX or troff (they work as a pipe of filters), than with a WYSIWYG like MS Word. You get more relevant data quicker with SQL querying a Data Warehouse than via some GUI front-end that only lets you use some opaque, pre-defined queries. GUI is meant to flatten the learning curve; CLI is meant to let you unleash power of tools you know well. GUI may shine when you do a task once in a blue moon, but CLI is the choice for frequent use. On the other hand, I've never seen any good CLI approach to browsing the web ;-)