Unix command line utilities were pipeable. Consumers never had use for IPC, most companies have way more important things to worry about
Unix command line utilities were pipeable. Consumers never had use for IPC, most companies have way more important things to worry about
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.
> 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
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.> 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.
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.
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 :(
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...