So, in an environment run strictly by the unix philosophy, there would be no transaction costs between switching from a spreadsheet to a word doc because you wouldn’t be running a gui – you would be sitting in your shell writing quick and dirty scripts.

Before you think that’s impossible in today’s world – that is how I work. I work in a major bank where we have to keep supporting foreign exchange wires and trouble shooting issues. We deal with 1000 rows of data.

I don’t work directly in excel – it would take weeks to do what I do in minutes.

I pull data out of Oracle into a flat file, write quick/dirty unix/awk scripts, build csv files, ftp them to windows, and then load them into excel for sending them out.

Many times, I have to work backwards, saving excel sheets with 1000+ rows into a CSV file, ftp’ing it to unix, and using an awk script to generate sql commands for the database.

There may not be a real benefit for command line applications, since they must still communicate with POSIX-compliant software. But modern desktop environments such as GNOME and KDE and related applications take real advantage today.

I thought the UNIX philosophy and elegance was in the pipes and filters model, along with the toolbox of individually useful bits and pieces. UNIX (and its nascent community) never espoused the philosophy of higher level, multi-activity user facing programs. The “philosophy” is one level down. Claiming it one level up is incorrect.

But the Unix philosophy is still a noble one to pursue, as other commenters have already pointed out. Again, I especially like the idea of hierarchical “one-use programs” with wrappers to make them useful as a bigger group. There’s no reason to embed a specific utility into a GUI skin when it can be abstracted out of it’s frame and be made more useful to everyone.

Diversity is the reason life exists, and is also the reason to live. If we’d all solved the modular program debate we wouldn’t have anything to debate.

(P.S. As for parsing dates, sed/awk do a fabulously fast job of that, making the task only “seem” onerous to those trying to parse with Python or Ruby or what-not.)

unix philosophy says “small is beautiful” and “do one thing well”, but vast majority of unix commands are not beautiful and doesn’t do one thing well. Lots examples… grep supports “-r” option, while it really should be just “grep” + “find”. “grep -r” itself has lots of problems. e.g. when you want recursive but only “*.html” files, it can’t be done in a simple way. Same with “find”… lots of problems, then there’s need for “xarg”. These applies to almost the whole unix bag.

also, i think this unix philosophy slogan arose in 1970s or 1980s. At the time, its competition afaik are Multics or later lisp machines. It’s before my time, but from what i read these systems are far better.

i think this joke summarize unix well at the time: http://xahlee.org/UnixResource_dir/_fastfood_dir/fastfood.html

also wrote about this here http://xahlee.org/UnixResource_dir/writ/unix_phil.html

Maybe this says more about the surrounding OS, the quality of integration, the user-experience and the implementation of this suite then about how it proves the UNIX philosphy fails? Woud this still be the case, if the surroundings made switching dead-easy? If they were actually very well integrated?

To take this back to the UNIX-philosophy:
Instead of writing my invoices in word, copy-pasting the calculations from my timesheets-CSV-import in excel, copy-pasting the address from my outlook addressbook (which, I can tell you s*cks), UNIX preaches the following:
One single application uses:
A program or library (not a suite, or an application!) that handles CSV-timesheets-imports and allows simple pre-definable turn-this-sheet-into-a-billable-table.
A single low-level central addressbook with proper API-able and parsable entries (like a sqllite, or couch database).
A dead-simple text-writer that allows me to enter some additional texts to my invoice.
A library or program that turns marked-up-text into PDF.

Now, that would be a nice invoicing tool. It uses the same addressbook my mail-client uses. It will find my timesheets and parse them for me. It will allow me to focus on the additional texts (instead of fiddling with spacing, font-sizes and indentations every single invoice). It is, therefore a truly UNIX-tool.

I think the flaw some people here are making is that they’re assuming that the Unix philosophy implies linearity – that everything has to be done by piping repeatedly. Why the assumption? The UNIX philosophy does not prohibit a hierarchical structure.

In the Office example, the UNIX philosophy wouldn’t dictate that you have to close Word and then open Excel. The UNIX philosophy states that if everything were coded well with the proper modularity, that it would be easy to write a wrapper program (which would incorporate, say, your GUI). So your wrapper program would automatically take your “Word” data and pass it on to “Excel”, and present you with everything transparently.

And note, of course, that the model here is simplistic. In the UNIX philosophy, Word wouldn’t be one unit, but itself a wrapper program.

I also disagree with the Emacs vs UNIX comparison. In fact, I often tell friends that Emacs exhibits the UNIX philosophy better than apps in UNIX typically do! The reason Emacs has become an “operating system” is the ease with which one can interconnect all the various packages built for it. It’s incredibly modular.

Finally, yes, there is some overhead to the UNIX philosophy (with reference to the example of dates). But you can’t have everything. Adhering to the UNIX philosophy gives you a lot, but at a cost.

Since typesetting and text layout has to account for formulas in various ways (for example, if you use it inline, the term (a/\sqrt(b/c)) needs to be placed at a different height than (\sqrt(a/b)/c) simply because the main fraction is at another level. You can’t do this with automatically objects that are simply images placed in the text. You can do it if you have math typesetting natively.

You could probably solve this by having a baseline property for OLE objects which sullies a generic interface for anything with word processing-specific information that isn’t even relevant to most data moved around that way. Not a great way either.

With Office 2010 math typesetting made its way in the other Office applications too, by the way. And it was quite a long way to get there – the whole feature started out even before Office 2003. And while he Office applications surely all share code to some extent it’s probably not just a matter of an afternoon to add math support to PowerPoint or OneNote. Remember that specifications have to be written, things implemented, tested, etc. Those are many man-hours and there is only so much planned for new features – something has to be cut – always. Unless you enver want to ship a product, that is.

P.S.: Another thing I’d rather have natively than as OLE objects would be syntax-highlighted source code listings. Still planning on doing such a thing for Word, I just have to find the time.

Also, as an example of a quite bloated standard Unix tool, ls has quite many options:

    usage: ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx1] [-D format] [file ...]

There are only 5 lower-case letters missing and 11 upper-case ones. There’s only so much you can express with single-letter options and that program is now probably well beyond the number of reasonable options.

Generally, the “do one thing and do it well” philosophy is probably hard to justify in modern GUI applications as well. You probably don’t want a set of single applications to manage, edit, export and print photos each with one of them. I just use Lightroom for that purpose and am happy it does many things (well, even).

Doing single, simple things well makes sense from a developer perspective and you find it again in libraries: Usually they don’t abstract everything away from you. Few libraries consist of a few high-level operations that are then easily modeled into a complete program that does exactly those tasks. Most provide an interface or n abstraction to an API or do a single thing well. It’s up to the developer to chain library calls and own logic to create something useful. Given that Unix started out as a playground for developers (and even today many people seem to assume that the only people who ever use Unix-likes are developers of the same system) it’s no surprise that the shell followed that premise. Still, libraries and plugins often have better interfaces between the parts that make things less painful at times.

In any case, while composing complex solutions from many smaller ones is a nice thing to have for a developer it’s less so for the end-user. Strictly separating functionality is bound to creep into the user interface as well and integration between those parts will often suffer. Unless you give the user the power to compose everything on their own as well – in which case they are developers again and the whole UX is only suitable for a fraction of the people.

We have other things where developer interfaces have crept into the general user experience for decades: file systems for example. There is hardly any user-friendly abstraction over files.

Ah well, I think this has become off-topic enough by now

Technical limitations: as you point, using an armada of little programs is not efficient, because launching programs has a cost. Furthermore, the plain text format is also inefficient: one program computes some date, convert it to text, pass it to another program, which parses the date string and do something else with the result. That’s just insane. And the fact that the glue programming language that’s supposed to do that, bash shell scripts, is not exactly the best language one can dream of, doesn’t help.

As you also point, often it is not practical to achieve this orthogonally. Text editors like Vi or Emacs are a good example: one just cannot replace them with ed + a pretty-printer + awk or M4 macros + a CVS for the undo function.

Omar suggested something that is better: plugin architectures. I would go a step further an put this solution upside-down: an architecture based on a scripting language to glue together libraries or software components. This is what some people try to do with TCL, Python or Lua. If only they could use them more as platforms than as scripting languages.