🚀 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.

Funny... it gets used that way.

> 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).

That's an implementation detail. There are systems that transparently
use shared memory where it's available. Someone recently sent me a
paper on it... quite impressive.

And, yes, having to encode all the data you need into a byte stream
does cost some performance, but it also forces an interface that any
language can talk to... and that you can route over just about any
reliable 8-bit data path (networks, serial connections, X.25, ...)
ever invented. And it's easy to run concurrently.

On the other hand different languages have different sets of objects
they can operate on. What do you EXPECT to happen when you pass an
object to Fortran, or a floating point number to Cobol?
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"