🚀 go-pugleaf

In article <1992Dec14.201155.9907@newshost.lanl.gov>, jlg@cochiti.lanl.gov (J. Giles) writes:
|> Having languages compatible only at the pipe-I/O level is not 
|> really acceptable.  It's too clumsy, slow, and inflexible to
|> be of any real use for production purposes.  Operationally,
|> a pipe is a weak subset of the functionality that should be
|> present in an interprocess communications package.  Semantically,
|> pipes are a very weak subset of function composition.  Among the
|> problems is the lack of type-checking across the protocol - all your
|> data must be reduced to byte streams (you *could* encode the type 
|> information into the stream, but who does?).  Another problem
|> is that all the communication requires two system calls, and on
|> most implementations: a trip through the system buffers for all
|> the data (both of these are *slow* and it's preferable not to
|> move the data at all).

Well, it depends.  In some cases, procedure call `compatibility' is a
good thing: although you can take it too far (eg VMS where practically
everything is call-by-reference for the sake of FORTRAN).

In some cases, however, the textual integration that UNIX is a shining
example of it useful: it helps the modularization; it means that itsy bitsy
programs can do itsy bitsy jobs and join together in a useful way.  Not
that I'm suggesting that this is a good way to write, say, a wysiwyg editor,
but it's not a bad way to write a text processing system (the troff family, for
example), because it allows you to do all sorts of other things to get
interesting and unssual spelling mistakse :-)

-- 
John Haxby, Definitively Wrong.
Digital				<jch@rdg.dec.com>
Reading, England		<...!uknet!wessex!jch>

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.