[flomo]

Agreed. And one could argue that Unix wasn't really popular because of the "philosophy", but because it would get out of the way and let you run big monolithic applications like OracleDB or CAD software or even Emacs and etc. So no popular application using "Plan 9 philosophy" ever emerged.

[hakfoo]

I suspect the appeal of the Unix Philosophy is strongest at the earliest phases of the system's evolution.

Once you've written some very basic boostrap tools, the "second generation" of stuff that adds convenience and flexibility are a lot simpler.

A trivial example: 20 seconds after you wrote "directory listing", someone will say "I want a directory listing, but sorted by date, and it would be awesome if it didn't immediately scroll past the end of my screen."

With Unix Philosophy tools, you might already have have a "sort" and "paginate" command, so it's just piping stuff together. They can do it themselves, or it will take 20 seconds to explain.

Without it, you're going to have to add additional options to "directory listing" (or parallel commands) to handle the sorting and pagination features. The tools get bigger and buggier for the same functionality.

Early Unix machines weren't much bigger than mid-80s PCs-- 512K of memory or less-- but offered a very rich command line experience compared with DOS machines of similar sizes.

Programs like database or CAD packages probably go monolithic because they're more "state dependent" than your usual command-line tools. "sort" and "more" can take their inputs from stdin and feed them out to stdout, and when they're done, forget everything with no damage.

That wouldn't work well for other packages. You could probably make a database or CAD system that worked as composable units, like `echo db.sql | db-query "select username from accounts where credit < 0" | xargs delete-account` or `echo image.dxf | add-circle -x 200 -y 400 -r 60 > image.dxf` But you'd spend a lot of time reloading and reparsing the same files. A persistent monolith that keeps the data file open and in whatever internal representation is most efficient is going to perform better.

Some use cases also have limited composability, because the user can only plan a few moves ahead. Tools that encourage interactive/experimental usage, like drafting software, might involve the user stopping every step or two to make sure they're staying on plan, and queuing up a series of commands could wreak havoc. Some of these packages ended up simulating composable tools through internal macro/scripting languages which still avoided the penalty of having to rely on the OS to orchestrate every single action.

[zozbot234]

> With Unix Philosophy tools, you might already have have a "sort" and "paginate" command, so it's just piping stuff together. They can do it themselves, or it will take 20 seconds to explain.

Sorting the output of textual tools like ls requires parsing which can be non-trivial. It's easier to do it by using a modern structural shell such as nushell.

[foul]

The pipeline part and the "do one thing well" can't make anything structurally serious for the layman. But Unix had gaps for that, that plan9 in its ways fills: it has GUI, a better shell language, coroutines and file servers. The application then has to be glue code you'd write in C or Rc, you may write pipelines for some things your application does but nobody can do Excel (the way Excel does) with just a pipeline...

[mjevans]

Imagine extending Plan 9 semantics with something like REST style protocols, but via the (virtual) filesystem layer rather than HTTP requests.

(Offhand, I've never touched Plan 9 but...) Hypothetically /proc/SOMEPID/db/DATABASE/SCHEMA/TABLE/various views which provide expressions in some order. Or /proc/SOMEPID/containerofthings/ and the directory listing is serviced by the application, as an enumeration of keys (filenames) to values (datasets). For a database the API would behave similarly to how ORMs operate since filesystems are inherently similar to objects.

[zozbot234]

Why be dependent on the /proc/SOMEPID/ path? Just write your process as a plan9 file server, and expose it in some arbitrary part of the filesystem.

[linguae]

I agree, but I believe the fact there are no popular applications that fully embrace the Unix/Plan 9 philosophy is the point of the philosophy. Generic tools that can be composed versus end-to-end applications. Both have their advantages and disadvantages, though component-based software doesn’t preclude the development of end-to-end applications using these components. In my opinion I believe the reason end-to-end applications are dominant is because it’s easier for companies to sell and market products over tools. Part of the reason OpenDoc failed was because companies that made a living selling end-to-end applications (like Adobe) didn’t want to adopt component-based software where the product (application) isn’t the main focus. Imagine if users could construct their own Photoshop out of discrete elements.

[pjmlp]

There were plenty of ActiveX lego components to build Photoshop like applications on Windows during the 1990's, back when buying libraries was a thing professionals would care about.

[pjmlp]

Even the UNIX philosophy is something that gets praised all around on UNIX FOSS circles, which I seldom saw anyone carying about on commercial UNIX systems, starting with my introduction to Xenix in 1993.

It kind of feels a bit of cargo cult, praising it all the time.

[foul]

The plan9 philosophy can't exist because there are no more three-button mice... UI aside, you have very cool technical differences with UNIX and most important of all daemons are file servers, you don't have to create or learn any new query style and path layout to work with them, you interact with parts exposed from a program writing (to) files and reading them, you don't necessarily need to read big chunks of data either if the program can expose just fragments.