Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!bu-cs!hen
From: hen@bu-cs.UUCP (Bill Henneman)
Newsgroups: net.ai,net.lang.lisp
Subject: Re: Multi-language systems
Message-ID: <259@bu-cs.UUCP>
Date: Mon, 18-Mar-85 11:12:11 EST
Article-I.D.: bu-cs.259
Posted: Mon Mar 18 11:12:11 1985
Date-Received: Tue, 19-Mar-85 06:13:21 EST
References: <242@bu-cs.UUCP>, <316@cmu-cs-k.ARPA> <253@bu-cs.UUCP>, <494@harvard.ARPA>
Organization: Boston Univ Comp. Sci.
Lines: 42
Xref: watmath net.ai:2637 net.lang.lisp:400

There are the technical issues about language-language interface which
can be sources of error, but generally they are documented (at least in
the source listings of the compilers/interpreters.  For example, the
LISP I use on the IBM 3081 puts extra information in an array header for
faster indexing: I have to reformat the array before I pass it to
FORTRAN.  This means that, before deciding to go multi-language on a
system, I have to do a calculation that the time spent groveling through
manuals (and sources) can be bought back by the added efficiency.

However, I my reference to Whorf was possibly to elliptic.  Whorf was an
American linguist who advanced the hypothesis that the language you
speak greatly influences the way you think about the world around you.
As I said, whether or not his hypothesis is valid for natural languages,
it is certainly true for computer languages.  Implicit in the fact that
I am writing a program in COBOL is the decision that the data flow is
important, and the control flow is trivial.  Similar judgements go into
any choice of language for any program I write.  I try to match the tool
to the job.  Each language has its own strengths and weaknesses, but the
price paid for the strength of any given language is that it imposes a
problem-solving style on the programmer.

Just as in natural language, computer languages cluster into families.
There is nothing hard about mixing FORTRAN & COBOL modules into a big
system (or FORTAN & PL/I).  I've done plenty of that sort of stuff.
It's when you move across families where things break down, and
especially where you try mixing an inherently interpreted language like
LISP or SNOBOL with an inherently compiled one like FORTRAN that things
get dangerous.

A system which is dangerously multi-lingual will, in my view, perforce
be difficult to maintain because it is opaque for the two reasons cited
above: some of the code will be obscure because it is faking an
environment for the sibling, and the rest will lack unity of style.
Speaking from experience, I can say that no one person is going to be
able to understand the whole system.  I've been programming since 1955,
and I've never met a programmer equally proficient in all languages.
Some languages match their thought processes, and some don't.  The
amount of worthwhile communication between a FORTRAN programmer and a
LISP programmer is non-measurable, because their fundemental ideas about
what programming is are irreconcilable.

						Bill Henneman