Exactly. Most of us write software for non-programmers.

Pipeable software is great for developers and computer scientists.

But for laypeople, they need a UI. They don't understand -- and don't want to understand -- the machinations behind the process. They have a business process and they want the software to model that business process.

And that business process is not going to be executable on a command line.

> Pipeable software is great for developers and computer scientists.

> But for laypeople, they need a UI.

Totally agreed with your points. Also, maybe I am completely out of touch, but there is nothing stopping people from using Unix utilities. The majority of my meaningful computing is done within a terminal emulator where the majority of my tooling is pipe-able. An example that also highlights this is Microsoft's work on PowerShell -- which is built to be used in complex pipelines (I think Microsoft is an interesting example because they have a history -- pre-2010 -- of being one of the biggest opponents to the Unix philosophy).

Where is this mentality in the original article coming from that pipe-able tooling is no longer an option for people who care about that? Am I just that out of touch in thinking that Unix/Unix-like tools are literally everywhere and building a command-line-focused/pipe-able ecosystem is better than it ever has been?

EDIT: some grammar and clarification on my points

> "(I think Microsoft is an interesting example because they have a history -- pre-2010 -- of being one of the biggest opponents to the Unix philosophy)"

Windows had system-wide IPC (OLE and COM/DCOM) since Windows 95 that Linux doesn't have today, and which I suspect Linux users don't even know they're missing. You want a spreadsheet in a word document, you could drag it in there and Excel as a component would appear inside Word. You want to extract JPG metadata in your VBScript, call WScript.Shell and lean on Explorer to do it. Array calculations? Automate the 3rd party J engine. Voice recognition in Python with PyWin32? Instantiate SAPI.SPVoice. System wide task/specialty-focused components not like installing a node.js library, but available to any language or any program which speaks the same interfaces.

It isn't /piping/ but it isn't everything-reimplements-the-world either.

> "An example that also highlights this is Microsoft's work on PowerShell -- which is built to be used in complex pipelines"

And sadly you have to drop away from the pipelines to fuse operations together to get decent performance.

    Get-ChildItem C:\Windows | Where-Object Name -like '*.dll'
    gci c:\windows |? Name -li *.dll

will not be as fast as

    Get-ChildItem c:\windows -Filter *.dll

because the first one has to generate pipeline data for every file only to filter most of them out, the second one can generate only the data which is needed in the first place. And this problem of fusing operations to avoid wasting resources is endemic to pipelines, not only to PowerShell - see Unix shells serialising everything to text at the output of a command only to parse it from text at the input to the next command, or how commands gain ever more options to do with filtering and processing, summarising and formatting, which aren't anything to do with the "one thing" they allegedly do.

I think your points are well articulated and educational to me as I am admittedly one of those Linux users that doesn't fully grasp/appreciate the cohesive nature of the system-wide IPC you are describing (even if I was on Windows I would still just stay in the terminal for most of my applications).

> sadly you have to drop away from the pipelines to fuse operations to get decent performance

I used PowerShell as an example because it's currently an important part of the Windows ecosystem and works very well with piping. In my experience using PowerShell (on Linux) as my daily driver I haven't noticed performance losses in using pipelines. That being said, maybe I'm losing more resources by not optimizing every command I run, but so far I am pretty happy using PowerShell while heavily using pipelines.

COM as far as I used it was always this incredibly opaque thing that no one understood. The only good thing is that you could generate C# code in visual studio for it, but the generated stuff is barely understandable and versioning with COM is another big issue.

> "The only good thing"

The good thing is that in dynamic languages (VBScript, Python, PowerShell) you can instantiate COM objects and call their methods in a couple of lines. I have never held the "oh but COM is badly designed and complicated inside" complaint in high regard, because the alternatives are either: it should be easy for programmers and if it's hard for users who cares, which is worse, or if it's not easy for programmers it shouldn't exist at all, which is also worse.

GUIs aren't inherently incompatible with composable data. Sharing in iOS and Android is an extremely rudimentary version of such. Then there was OLE in Windows (mentioned in another comment here) and Apple's OpenDoc (controversially canned by Steve Jobs).

It's a harder task to specify than just piping text, and the period of corporate/consumer computer history GUIs have come to maturity in has made it less likely to happen. Which is a shame. With a modicum of luck and the right standards and incentives, marvellously useful tools for active humans could have come about. It seems unlikely to happen now. Most computers are essentially training clickers for passive consumers.

There's no reason why we couldn't come up with a nice GUI than piped output.

I don't think the problem is GUI specifically - the problem is poor/no provision for automation. Our widely used apps either discourage (by making it difficult), or just do not enable, anything other than manual actions.

Take the MS Office suite, for example. The entire suite is built round highly manual operations - the common operations are provided and triggered manually. But if it's not provided, good luck. Just say, you want to print your document with the odd pages rotated ... it's not going to be easy ... perhaps print to a pdf, then use an external editor to MANUALLY rotate each odd page! Or print odds and evens, then MANUALLY interleave the pages. It can be done, but we're encouraged to do it manually and mechanically :(

For virtually any issue you have with Office the answer is to find the Python module for the document format and write a quick script. Then, instead of some arcane shell monstrosity that’s easier to rewrite than edit, you have a script whose function is obvious and testable.

Rinse and repeat for all of the actual examples people come up with for how pipelines are better. They’re not magic, they’re just a tool.

https://www.geeksforgeeks.org/working-with-page-orientations...

In the old days Office came with a macro recorder that you could use for that kind of thing.