Re: Is Systems Software Research Irrelevant?

[Daniel Weinreb <address@hidden>]

>But I can't help wishing I was hearing about some
>academic projects to "compete" with .NET/JVM but with more of an orientation
>towards supporting more sophisticated language technologies, w.r.t. type
>systems, functional features, etc.
>
Actually, at LL1, I was under the impression that we were hearing about 
at least one plan
for a  project to compete with .NET and JVM, namely the new Perl 
implementation
strategy.  As I said at the workshop, I think it would be valuable for 
someone to write
a paper specifically about why .NET and JVM are not adequate for Perl's 
needs, and
what needed to be added for Perl (and possibly for Python).

>
>
>Perhaps researchers would either say that these systems aren't all that
>interesting - "just another virtual machine" 
>
Actually there seem to be a lot of researchers writing papers about the 
JVM, so I guess some
researchers don't think it's entirely boring...

>
>Oh c'mon, rant away!  Somewhere in your perspective on pipes may be the idea
>which will spark a new paradigm in OS development, and Rob Pike will be
>forced to post an updated "happy" version of his document! ;)
>
Real component architectures, in the sense of an architecture that lets 
two programs interoperate
even if the programs were written by disparate people in disparate 
places under very different
adminstrative environments, require *more*, not *less*, declarative 
semantics.  CORBA and
RMI are just a start; at least they give names to operations and specify 
input and output types.
The whole WSDL/UDDI/SOAP path is a somewhat improved version of the 
same.  But even
that's really not good enough for a lot of things, because the above 
technologies only deal
in single request-response interactions, whereas a lot of real 
interactions have a lot more steps
than that.  You need to have what eXcelon's BPM product (what I used to 
work on) calls
"collaboration definitions", also known as the BPSS stuff in the ebXML 
standard.  These
are basically declarations of choreography of messages: A sends a foo to 
B, and then B
sends a bar to A, and then A might send either a baz or a frob to C, and 
so on (picture
a little flow chart). And the protocols have to allow for asynchronous 
communication, too.

Pipes don't have any declarative semantics at all. It's like programming 
in Lisp using
only cons cells everywhere, never using structs or classes.  No 
compile-time typing
and no run-time typing: if things don't match, you just get garbage out 
with no coherent
error message.

>
>Still, I don't think any of the modern component systems have reached the
>level to which Unix tools get mixed and matched, ad-hoc, by "end users"
>(smart end users, but still).  I have no doubt things will reach that point,
>but there's a lot of complexity still to be dealt with - a much more
>ambitious problem domain.
>
I see what you mean; of course that's a very different view of the goal 
of "component architecture"
than what I'm talking about above.  That's what I meant in earlier mail 
about it not being clear
what we mean when we ask for a "component architecture".


-- Dan

>