Re: Multiple Languages v. Multiple Paradigms

[Michael Vanier <address@hidden>]

> Date: Fri,  8 Mar 2002 12:03:37 -0500
> From: "Peter J. Wasilko, Esq." <futurist@cloud9.net>
> 
>     In seeking the ability to program in multiple languages, which level(s)
> matter most?
> 
>         a) Surface Structure / Syntax
>         b) Library Routines provided by each language's standard library(s)
> which might be taken as primitives vis-a-vis the multiple language user 
>         c) Actual Evaluation Semantics
>         
>     Are multiple languages, in the sense of discrete runtime implementations
> necessary, or could their advantages be achieved in say Scheme with the addition
> of an appropriate foreign function interfaces and a small number of special
> forms and syntactic macros to support the semantic differences among the
> supported languages?
> 
>     We have seen a number of translators mapping assorted languages to C code
> calling a runtime library to provide dynamic functionality. 
> 
>     Would it be feasible to go in the opposite direction and design a new
> dynamic language that would support the combination of blocks having alternate
> evaluation semantics and then use multiple parsers to support "skins" to read
> source code written in multiple languages? 
> 

The approach of having multiple parsers to support "skins" as you describe
it has been suggested many times (once by me, on this list).  To my
knowledge, it has never been implemented, perhaps because it's too
difficult, perhaps because nobody was sufficiently motivated, or for some
other reason.  It's usually proposed in the context of making one existing
language look like another, and there, the problem is that different
languages differ in their semantics in large ways and small, and nobody
seems to be happy with the idea of a language X that looks like language Y
but has the semantics of language Z.  The guile scheme people hit this
problem and pretty much abandoned the idea of multiple language translators
(or put it on hold indefinitely).

I would say that all three of your levels are important.  To be able to use
libraries written in another language transparently and with little or no
additional cost relative to what the user of the language it which the
library was written would face would be a huge win.  Being able to use a
surface syntax that was optimal for the task at hand would in many cases be
a major win.  But the semantics are really the big issue.  Different
languages have different strengths and weaknesses, and I have long since
stopped believing in an uberlanguage that could do everything as well or
better than any other language.  To give one example: garbage collection is
incredibly useful in the sense of making a programmer's life easier.
Direct pointer manipulations (like in C/C++) can be used effectively to
make speed-critical code much faster.  These two language-related features
do not live well together.  You can do GC in C/C++ with conservative
garbage collectors, but there are tradeoffs that you would not have to deal
with in a language that doesn't have pointers.  Similarly, there appears to
be some fundamental tensions between statically-typed and dynamically-typed
languages, between statically-typed functional programming languages and
statically-typed object-oriented languages, and so on where there is no one
perfect way to do things.  This may be because we haven't found the right
approach yet, or because there are fundamentally irreconcilable semantic
differences between programming languages.  I think the latter is more
likely to be the case.  If so, then it makes sense to be able to code
different parts of an application using the language with the appropriate
features for that part, which leads us to the issue of inter-language
unification.  To do this well, if it can be done well, is a major challenge
for the next generation of programming systems.

Mike