[georgia_peach]

> PowerShell got this right

I think it's more of a trade-off between portability & ergonomics. PowerShell wins on ergonomics, but that also commits the developer to a fairly large binary encoding interface when something smaller would do. Windows does more of the lifting for me, but it also locks me into their ghetto. And even if the whole object encoding format were already wrapped up into a nice MIT licensed library, I might not want to commit to another dependency just to output a little text.

The nice thing about text is that (with UTF-8 at least), I don't have to worry about endianness (like when ssh-ing something over the wire, to a machine with a different OS and/or architecture), and we know not to trust it. Serialization/deserialization has a cost, but not a terribly steep one.

I believe the bazaar has won for a reason here.

[naikrovek]

PowerShell is open source and available on non-Microsoft platforms, but even if it wasn't, that alone isn't enough to judge the concept of passing objects instead of text.

there are many ways to implement such an idea, and PowerShell is only one of those ways. I think PowerShell did it well, and I recognize that there could be better ways.

separate the idea from the implementation.

> ...I might not want to commit to another dependency just to output a little text.

how complex of a dependency do you think that would be? "number of dependencies" is not a valuable metric; "complexity added by dependencies" is definitely valuable, so consider that, instead. a dependency which allows textual output, if it somehow weren't already in the pipeline, would be very small indeed, and would add almost zero complexity to the project.

and I don't think individual applications are the right place to add this, anyway. the terminal/shell should know what to do if the object you pass to STDOUT is self-describing.

[georgia_peach]

There's already a growing body of tools that choose JSON as their serialization format, and it all works well enough--even though most shells and terminals are oblivious to it. If the dependency is inconsequential, there you go--use JSON.

Outside of optimizing-away a pipe (built-ins vs processes), I'm not sure if the shell even needs to figure into this.

Several of the newer terminals already support base64 png/gif/jpeg escape codes (ex: https://iterm2.com/documentation-images.html). Get the different projects on-board for a new escape code to handle a full-blown MIME blob (make it work just like image, but w/ mandatory mime type prefix), then everything would be covered.

The boundaries of concern between process/shell/terminal were fairly well-drawn to begin with. Some form of mandatory interchange more structured than "get a byte, get a byte, get a byte, byte, byte" is just going to end up as another VM ghetto like emacs. I like emacs, but one is enough.