[xienze]

I think it boils down to a lot of people having a fundamental misunderstanding of what makes PS different than Bash, i.e., not understanding how significant it is to have processes communicate through piped objects versus piped text, which is far more brittle.

[AnIdiotOnTheNet]

I think it is simpler than that, it's web and unix devops who just don't want to learn new tooling and are upset that it isn't exactly like bash/core-utils.

[makecheck]

Since it is impossible to force all inputs to be well-constructed, text acts as the more predictable interface. Once I learn a bunch of command-line tools for processing text, I know exactly how to compose commands or post-process text from a file or extend the usefulness of a program that doesn’t happen to produce output I want.

While there may be something “brittle” from time to time, in my experience this just means it was possible to tackle the problem with text when the alternative would have been to have no way to do it at all.

PowerShell feels like it wants everything to be structured perfectly, and “perfect is the enemy of the good” applies. Sometimes, I don’t care if there is a way to perfectly structure a particular input because many use cases just don’t have stringent requirements.

[xienze]

> Since it is impossible to force all inputs to be well-constructed, text acts as the more predictable interface.

Disagree. If the program decides to change its output formatting even by a small amount (like going from a GNU version of the program to the BSD version, where such things can happen), e.g. changing the column order of two items, whoops, your script is broken. When you deal with object versus textual output the textual representation of a program can change all day long and you're not affected. The only breaking change is a change to the output object format (like renaming or deleting properties).

Writing scripts that rely on text being output in a specific order with a specific format is very brittle in my opinion.

[makecheck]

Robust scripts require diligence appropriate for the environment. If you’ve deployed systems with different default tool versions, you factor this in, e.g. by installing a common version that both can use (or just make scripts that can figure out how to work either way). Two versions of a tool isn’t really any different than two versions of a compiled-in API, except that APIs tend to be more rigid (not always, e.g. some languages allow runtime querying).

There’s a common rule in Unix-like systems that essentially says “inputs are liberal, outputs are conservative”. It matters to have programs that can adapt, because this makes a lot of things more practical.

[tom_]

Assuming the system is put together correctly, all inputs certainly ought to be correct, because whatever component is producing the corresponding output simply wouldn't have compiled if they weren't...

[zamalek]

Powershell deals with text too, it just converts it into regex match objects.