[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is Systems Software Research Irrelevant?
>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
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
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
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
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
and no run-time typing: if things don't match, you just get garbage out
with no coherent
>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".