🚀 go-pugleaf

In article <id.L8RV.IQC@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <1992Dec10.192524.25311@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
|> [...]
|> > It works *really* well in programming environments in which several
|> > languages are available and are all compatible at the procedure call
|> > level.
|> 
|> It also works really well in UNIX, where programs are expected to work
|> together. I write tools in whatever language is best suited for the task.
|> Sometimes I write them several times as the requirements change: starting
|> as a shell script, then moving to awk/perl/tcl/..., and then to C. I have
|> one tool that's a combination of shell and C that started as Fortran and
|> PL/M and migrated bit by bit as time went on...

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

No, all things considered, the level of compatibility needs to
be at the procedure call (or closer) for adequate interlanguage
operation.  This could be accomplished on each system by standardization
of the internal representation of data types which are common to most
languages, standardization of the procedure call protocol (if your
system hasn't already done so), and standardization of the format of
relocatables (which is already the most common way to proceed).
Finally, standardization of the most common data structuring 
mechanisms (structs, lists, unions, etc.) at least with regard
to their internal storage would be required.  None of these are
inherently beyond the realm of possibility.

Of course, part of my objection to UNIX is that many of the languages
and/or tools you mentioned are so poorly designed, hard to learn and
use, and so full of tricky incompatibilities that they are not really
acceptable even if they were more efficient, etc..

-- 
J. Giles