Hacker News Reader

Comment by wtracy | Hacker News Reader

I'm loathe to hand credit to Microsoft, but I think they're onto something with Powershell. Rather than being limited to passing text streams around, Powershell commands pass full-featured objects back and forth (with callbacks and everything!).

This flexibility really seems to break down the transaction costs that the original article talks about, when compared to traditional Unix pipes.

I'm still trying to come up with a Linux-y way to do this. Microsoft can mandate that all Powershell commands run under the CLR (and therefore can talk to arbitrary implementations of some CLR class) but any FOSS equivalent is going to have to deal with people wanting to interface programs written for a dozen different runtimes (and probably even some C code running on the bare metal).

View on HN

Not to state the obvious, but this step was taken by major scripting languages decades ago with the minor restriction that your program had to run within one executable. Furthermore the idea of encapsulating objects in a way that could be passed between programs is not much younger - in the early 90s you had (still used) protocols for that like CORBA and PDO. And Microsoft was not far behind with its ever evolving OLE/COM/DCOM protocols.

I have no idea how good Microsoft's current implementation is. (Given how many times they have tried to tackle it, it wouldn't surprise me if it was pretty good by now.) But it isn't as original as it may seem.

Much of the simplicity which renders multi-command, single-line pipe chains facile to the posix shell user would be lost if the interchange format was any more complex than plain text.

If you need fields, then separate them with a text delimiter, if you need something more complicated, then maybe you should be using a programming language, or piping between scripts in a language with good text serialization.

Putting aside the fancy words, I agree.

Given the power of any computer (even those 30 years old), it's enormously powerful to be able to drop one segment of a pipe-chain and look at the output. Funny that I'm facing a similar issue now that some of the server world is going Javascript: "console.log(X);" doesn't necessarily tell you the whole story about X. Exchanging objects is 14% too complicated and anything more than 0% too complicated is too complicated.

> it's enormously powerful to be able to drop one segment of a pipe-chain and look at the output.

But having more complex objects instead of text doesn't stop us from having that. The objects just need to have some kind of to-string method that the shell uses.

It does hinder you, since string serializations will usually be an incomplete (or worse, inconsistent) view of an object. With Unix pipes, their string serialization is all that it is.

besides the toString if we could get a decent amount of the objects to be public we might have simpler formatting rules.

What simplicity? http://news.ycombinator.com/item?id=2229833. Structured data will give much more simplicity as everything (yes everything) requires some form of structure to parse. As a snarky example: for f in /usr/bin; do $f --help; done now tell me that these don't need structure. Also how is structured data any less parsable than unstructured data? It's all text one has a known format the other doesn't

> Much of the simplicity

It's not simple, it's primitive rounded in the corner.

If all you have is raw blobs of data in pipes, you can't grow up when you suddenly realize need for something more complex.

See the story with adding UTF-8 BOM support before #! in Linux kernel.

I think this depends a lot on how you define simplicity.

If we define simplicity as: a plain text interchange format, then clearly by definition a text based shell is simpler.

Piping objects instead of text allows a single command to do more, as it can operate on any of the object's properties that it understands. From a user's perspective, I believe, that this is simpler - however I will acknowledge that this is somewhat subjective. For example: The command ls | sort LastWriteTime would print a list of files sorted by their LastWriteTime. The command ls | sort Length would print a list of files sorted by their size. Doing this in bash is more difficult as it requires additional commands to parse the output of ls.

There's an experiment in Squeak to let plain Unix pipes intermingle with piping between Smalltalk/Squeak objects: http://wiki.squeak.org/squeak/1914. Not sure if it could be generalized, or how usable it ends up being.

To quote from a random mailing list post (http://www.mail-archive.com/pharo-project@lists.gforge.inria...):

The syntax is a mashup of Smalltalk and unix shell conventions. The pipes are OS pipes where necessary to interact with external programs, or an object that minics OS pipe behavior if the "commands" being connected are Smalltalk expressions or command objects.

I would suggest that the Linux-y way to do this would be to pipe JSON between applications. The even-more-Linuxy-way would be to have an option to use YAML instead.

This article doesn't really cover new ground. Software engineers have known about this for many years and Microsoft's OLE and Apple's ill-fated OpenDoc[1] were developed to address some of these issues.

[1] https://secure.wikimedia.org/wikipedia/en/wiki/Opendoc

"I'm still trying to come up with a Linux-y way to do this."

How about the interactive python shell?

True that it locks out all other runtimes, but given the massive set of libraries, that may be a small price to pay? Same applies to <your favorite runtime with lots of libraries>.

Reply on news.ycombinator.com