3 ms·

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.

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.

heywoodlh 4y ago
> 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
- jodrellblank 4y ago
  > "(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.
  - heywoodlh 4y ago
    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.
  - tarranoth 4y ago
    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.
    - deleted 4y ago
      [deleted]
    - jodrellblank 4y ago
      > "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.
aussiesnack 4y ago
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.

heywoodlh 4y ago

> 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

jodrellblank 4y ago
> "(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.
- heywoodlh 4y ago
  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.
- tarranoth 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - jodrellblank 4y ago
    > "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.

aussiesnack 4y ago

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.