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.
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.
> 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
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
Get-ChildItem c:\windows -Filter *.dll
> 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.
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.