[E-Lang] Draft Kernel-E DTD & Sketch of translation to debuggable Java

[Mark S. Miller]

At 01:49 PM 9/26/00 , Dan Moniz wrote:
>Perhaps, but JOSS is Java specific at one end, at least. Userland made XML-RPC
>because they were dealing with a Java-less world powered primarily C and Perl,
>if memory serves. 

"Language specific" is a funny thing.  JOSS & RMI make no bones about being 
Java specific.  CORBA and SOAP claim to be language neutral.  What do these 
claims mean?  It is certainly the case that Java programs have an easier 
time with JOSS and RMI than Smalltalk or C++ programs would.  For the 
"language neutral" systems, the relative amounts of pain for clients in 
various languages may be better balanced, giving real meaning to the claim 
of neutrality.  However, this compares relative pain along the wrong 
dimension. Notice that a "language specific" system designed for an obscure 
language no one uses of might appear language neutral by this standard, 
since the pain imposed on the non-obscure languages may be balanced.

This is essentially the situation with CORBA -- even though there was no 
obscure language, there may as well have been.  CORBA has as much of its own 
idiosyncratic semantics for each language to adapt to as any 
language-specific system would have.  Indeed, I don't see how it could be 
otherwise, if the standard has enough semantics to enable inter-operability 
among objects in different languages.  So, without knowing SOAP or XML-RPC 
well enough to say this with confidence, I'd guess either
1) it's true for them as well, or
2) they haven't specified enough semantics to enable cross-language 
interoperability, or 
3) they've discovered a new principle of protocol design that they haven't 
called anyone's attention to.

Comparing pain the other way, we may say that standard X imposes strictly 
less pain than standard Y across languages A, B, and C, iff for at least one 
of these languages X is less painful than Y and for no languages is Y less 
painful than X.  It may be the case that X is designed around the semantics 
of language A while Y is designed to be language neutral.  However, if X is 
strictly less painful, there's no reason for B and C programmers to prefer Y 
to X.  I believe this to be true for the substitutions:

X = JOSS/RMI
Y = CORBA
A = Java
B = C++
C = Smalltalk

I don't know if this is true when Y = SOAP or XML-RPC, but I suspect so, 
except for the one advantage of these XML systems: a standard human-readable 
textual format.  Once I build a XML <-> JOSS converter, the 
human-readability should no longer be an issue, and we'll be in a better 
position to compare it to these other proposals.

We should expect an advantage across languages for well designed language 
specific system which are specific to well designed languages: They already 
have a well thought out semantics to start from, and good language designers 
have in general designed much better semantics than good protocol designers. 
For purposes of these points, Java counts as a good language design.  CORBA 
has a semantics that could have come from being language specific for a bad 
language.

In any case, I'm not advocating JOSS/RMI of course, but JOSS/Pluribus 
http://www.erights.org/elib/object-pluribus/index.html , which is E-specific 
in the above sense.  My immediate need for the converter is simply to help 
me debug. But to accommodate current tastes, I may eventually allow the 
connect-time protocol negotiation to negotiate to use the textual protocol.  
Given the converter, it should be painless to support this. 

Strange isn't it? Using the massive MIPS the hardware guys give us to enable 
programs to speak to programs in human-readable notations.  If a readable 
tree calls in the network and no one reads it, ... ?


>SOAP was a collaboration between Documentor, Userland, and
>Microsoft (at least in the beginning), and I don't see MS pushing anything Java
>these days, not even J++ or MSJVM.

Yup.  By winning their lawsuit, Sun may have come out behind.  Microsoft's 
C# and .NET initiatives also look like interesting challenges to Java.  If 
Microsoft plays their cards right, I can imagine a someday working on a 
compiler from E to the C#.NET virtual machine instruction set.  It some ways 
it looks like it could be a better target than the JVM for compiling E.

Thanks to Ken Kahn for drawing my attention to these.


>... The presenter
>quickly backpedeled and said he meant that the ROPE tool didn't support large
>data sets, although the SOAP standard does.

Well, at least he did backpedal ;)


         Cheers,
         --MarkM