[Crito]

I can write *nix command-line utilities with ease in any language that I please. Can the same be said for powershell utilities? My understanding is that you are pretty much restricted to using CLR languages.

If we are accepting that sort of languae lock-in, I'd rather get something like scsh off the ground.

[Someone1234]

That's a little circular. You can use any language you please because all languages support pipes as a concept and "understand" stdin/stdout/stderr, etc.

There's nothing inherently linking the CRL to using objects within pipes. You could use for example JSON if you really wanted.

[Crito]

Reading/writing to/from files is a FAR lower bar than linking with the CRL. It's a lower bar than even using JSON over pipes; most languages will have good JSON libraries but none of them are as trivial as reading/writing lines to a file.

I'm not opposed to lifting ourselves above text over unix pipes, but I think that if we are going to do it then we should go in for the penny, in for the pound. Such a system will be incompatible with existing unix tools, so we might as well drop all the technical debt. I don't think powershell is a large enough break from the traditional unix setup.

Aside: I've noticed that there is an open source implementation of Powershell for Mono called `pash`. Does anybody use this?

[Someone]

That is not language lock-in, it is ABI lock-in, and that is exactly the same with Unix pipes.

You can complain that the increase in ABI complexity isn't worth the extra features, but I don't think it is fair to complain about increased ABI complexity, period.

[Crito]

> "Reading/writing to/from files is a FAR lower bar than linking with the CRL."*

If I want to write a unix utility in C, or Java, or C#, or Lua, or Racket, or postscript, or brainfuck..., I can. Not just in an academic sense, but in a "it is actually reasonable and trivial to do so" sense. The list of programming language implementations that cannot read/write to/from files (knowledge of the concept of "pipes" is unnecessary, the user's shell opens those) is vanishingly small.

For the average developer who just wants to use Powershell/bash/whatever, it is absolutely language lock-in.

[pjmlp]

It is a common misconception that Powershell is CLR only.

You can also make use of any COM, DCOM, or plain dynamic library in the shell.

There are also text formatters for interoperability with older scripts.

[Arnavion]

PowerShell utilities are implemented as CLR classes inheriting from a particular base class. As such, they must be written in a CLR language (or PowerShell itself, of course).

Edit: Of course, you have the option of writing a minimal wrapper in PS that shells out to your other-language command but the interface between PS and non-PS programs is still based on a string commandline.

[jude-]

The other key limitation of PowerShell is that its commands all run in the same process (e.g. PowerShell is akin to a REPL). By contrast, UNIX programs each run in their own process, giving the programmer a much greater degree of freedom in the design and implementation of each program.

You can do IPC with PowerShell [1], but it's nowhere near as simple as UNIX-style piping.

[1] http://coders-corner.net/2014/05/11/inter-process-communicat...

[Arnavion]

PS has the concept of jobs, an amalgamation of code and environment that is serialized to a separate powershell.exe process (potentially even to a different networked Windows machine). Communicating with these remote commands is identical to communication with a command - piping in and out of objects.