>>21
Yep, the guy wants us all to waste a lot of time and effort implementing over and over what the shell should be implementing. He's either fresh from Windows, or not a programmer at all, or has simple gone through the Unix-Haters Handbook, as has been said above.
>>22
I don't think you know what the word means.
>>24
I don't understand why they should be files. What do you gain?
What you gain is a great deal of simplicity. You can write to anything with any program without making any modifications at all, and likewise read from them. You could bring a remote computer's filesystem or sound card or network connection (etc.) into your local namespace and then write to it and/or read from it. No knowledge of single-purpose,
ENTERPRISE QUALITY, byzantine APIs required, and not a sockets API in sight. Just standard read/write calls.
What if I have an application managing a ton of connections from a lot of different peers?
What of it?
I mean why not make tools able to export their API like a library, so when it comes time to make a program that also needs to read png files it doesn't have to spawn a whole fucking process and redirect IO and all sorts of crap, but instead just link to the png tool (statically or dynamically), then have the linker or OS load everything except the CLI argument parsing junk.
If you're going to all that effort (there's a lot you need to know about that binary, and a billion things can go wrong) then you might as well just transplant that png reading code into your own program.