If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASCII. The choice to use "text" came first and the ecosystem came afterward.
"Text" makes a good lowest common denominator because it's low. Everything, including humans looking at it, can deal with text. Essentially all programming languages on all platforms provide basic primitives analogous to getline(), find_first_of(), substr(), etc. You can take text from Unix and easily do something useful with it on any arbitrary platform.
MSIL assumes an entire infrastructure that isn't universally available. You can't take MSIL from Windows and easily do something useful with it on any arbitrary platform. It requires you to have a solid .NET virtual machine for your operating system, an API for dealing with MSIL, bindings for that API in every language you want to use, etc.
There is nothing analogous to convert MSIL to. EBCDIC and ASCII both have a representation for 'A'. Only .NET has "Microsoft.Win32.Registry.CurrentUser.CreateSubKey()".
In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?
In UNIX, you have bytes, and the underlying system doesn't know what they represent. Most tools assume they're ASCII or UTF-8 (or whatever) encoded text, but that's all they agree on. In practice, you're working almost always working with structured data - tables or lists or mappings - but you have to remember that for the output of this program, you want to cut on '=' and take -f4, and first you need to pipe it through head and tail to clean up some junk output[1], and this other thing for that program, and whatever.
[1] This is a way to get the `time` field from the output of `ping`.
That's because the object pipeline is functionally analogous to function chaining within a single runtime like in Python or Ruby, not streaming data between arbitrary executables like in Unix pipelines.
This would be a lot clearer if PowerShell advocates compared it to things that it's actually functionally analogous to, but they are trying to position it as a Unix shell competitor.
No it is not. See my response below.
Of course, this kind of piping is present in nice languages that precede the PowerShell.
A one page Lisp macro will give you a left-to-right syntactic sugar for filtering. Clojure has a threading operator, Ruby has cascades of dots: object.{ blah }.foo().bar() ... and so on.
Pipelines in Unix shells use OS-level functionality to connect standard streams of data, often encoded as text, between arbitrary executables written in any language.
The reason this is confusing is because one of the main tactics used in PowerShell promotion is to disingenuously compare PowerShell's "object pipeline" to Unix pipelines in order to try to make it appear to be more novel than it is, when they should be comparing it to what it's functionally equivalent to, which is function chaining within a single runtime.
If PowerShells pipelines are merely equivalent to function chaining, then you should have no problem replicating the following very simple pipeline with function chaining in Ruby, Python or JavaScript:
cat log.txt -wait | sls "error"
But I am curious: Why is it important whether the pipelines could be implemented using function chaining or not? PowerShell is a shell where I interact with the system through commands. Yes - those commands are not the typical Unix executables - but they act as commands within the shell
Is your problem that it is not a Unix shell? You could equally well say that Unix shell pipelines are just processes connected by file descriptors. That is factually correct but does not represent the true utility of pipelines.
PowerShell pipelines are not file descriptors. PowerShell commands do not execute in separate processes. But PowerShell commands are versatile and can be combined in a way analogous to Unix shell pipelines where the output of one command is consumed and acted upon by the next command.
The object of a operating system command line shell is to expose the operating system features to the user of the shell. Why does it matter whether it uses Unix file descriptors. Even if PowerShell pipelines were equivalent to "just" chained functions, why does it matter?
I get the point that you need the .NET runtime to run PowerShell, because it is implemented using .NET. At what point do we consider a runtime part of the operating system. When it is intrinsically distributed with the operating system and cannot be uninstalled?
Non-ASCII has been supported for a long time.
I used "ASCII" instead of "text" to stress that "text" is just a protocol like anything else. The UNIX I'm running is set to use UTF8.