Hacker News new | ask | show | jobs
by pxc 1420 days ago
> The baseline is only text and files on systems that don't have anything better to offer.

Also pretty much all external programs on Windows. Anything that isn't itself implemented as a PowerShell cmdlet has this problem. And it's all shell-specific.

1 comments

Not really, if it’s a .NET assembly Powershell can dynamically load, call and use types from it. Not to mention first-class support for standard data interchange formats like JSON, XML etc without having to convert back/forth from text or use tools to process it.
In a few situations, actually calling .NET code from PowerShell doesn't suck, like setting persistent environment variables.

But in tons of situations actually doing anything that way involves a ton of boilerplate, and it's very clunky. It's acceptable for automation, but it's not something that feels very good to do in an interactive shell.

Stuff like Convert-FromJson is nice, but it's not as nice as whole ecosystem there the interchange format for external programs is sort of just 'understood'. It's also not streaming— it reads in a single JSON object as a string. So you need some extra boilerplate if the expectation is that you're piping output from a command that yields a stream of data.

PowerShell is great, but an environment where streaming objects in some other format between different programs, regardless of the languages they're in or the runtimes they use, would be better and closer to a real version of 'Unix pipelines but with objects'.