On 6/13/05, Humberto Massa Guimarăes <[EMAIL PROTECTED]> wrote: > What Olaf *really* seems to want is a resource like the new (vapor?) > Monad shell from MS. Which can be a good thing, if done right, but > is generally a waste of CPU and memory, if you ask me. As you said, > there is not a lot of difference between > > ls *.ab | fields name, size | table > > in Monad and > > printf "%-50.50s %d\n", $_, -s $_ for <*.ab> > > in Perl. The domain is necessary anyway, ie, you have to know Monad > to understand the first, you have to know perl to grok the second.
Except that in Perl you have hard-coded the size of the name field and hard-coded sizes are almost never optimal (either too large or too small in most of the cases). > > > XML is just _terrible_ for human input/output. > > > > It's not meant for human IO, it's meant for IO to the next chain. > > The final chain would then process it to normal text output. > > Even so; imagine a long (6 links) chain of things. Each of them > would have to unserialize the input and serialize the output (XML no > less! big overhead!), besides trying to know if its input is xml or Note that I said structured (XML-like) IO. I didn't say XML. I'm sure an implementation without big overhead is possible. > not, if its output should be xml or not. In the Monad case, it > *seems* that what is passed around are (DCOM?) objects, lowering the > overhead a litlle bit, but there is a lot of overhead nonetheless. > And it's still easier to use a tool (like Perl, Python or Ruby for > instance) that can do the job you want (look my example above)
